Why ChatGPT Can't Predict the Future — and What EU Firms Use Instead

LLMs are the best summarizers we have. That's the problem

Ask ChatGPT to summarize your customer churn table and it will deliver a clean, structured briefing in seconds. Ask it to predict what churn does next quarter, and it may deliver another clean, structured answer — without the validation that a proper forecasting system requires. This is the central criticism in a recent analysis by The Neuron, which asked a question many teams are already exploring: can the same model that summarizes data also predict what happens next?

The answer is more limited than the fluent output suggests. LLMs are trained primarily to predict the next token, not the next quarter. When you feed them a table, they process a representation of rows and columns as input text or other model-compatible data. That does not by itself give them the validated statistical model, calibrated uncertainty estimates, or time-series evaluation needed for reliable forecasting. A great summarizer can describe data beautifully; a forecast still needs to be tested against historical outcomes. An LLM may assist with that analysis or call an external forecasting tool, but its explanation is not evidence that its prediction is accurate.

The gap matters because teams keep treating “understanding” and “predicting” as the same skill. They are not. Reading a map is not the same as knowing where the storm will be tomorrow.

Let's do the math on LLM “forecasting”

There is a cost angle too, and it can turn an unsuitable forecasting workflow into a budget problem. Say you want to analyse churn for a mid-sized customer base of 100,000 rows, and you tokenize each row at roughly 500 tokens — a hypothetical mix of features and transaction history. That is 50 million input tokens for a single pass over the table. At a hypothetical rate of $0.20 per million input tokens, the calculation is: 50 × $0.20 = $10 for one input pass, before the model writes a single prediction. Each forecast output would cost extra. If you ran that same pass monthly, the input-only cost would be $10 × 12 = $120 per year, not a four-figure annual bill. Larger tables, repeated prompts, tool calls, and output tokens could raise the total, but the exact price depends on the official model and tier used.

The $0.20 figure above is therefore only a hypothetical example, not a confirmed current OpenAI tier or product price. The more important issue is not just the token bill: a cheap answer is still unsuitable if it has not been validated against the forecasting task and cannot be audited properly.

That is why, as The Neuron notes, there is growing debate about spending money trying to force LLMs into structured predictive roles. The demos can look great. Production dashboards still need measured forecast error, reproducible inputs, and monitoring.

Tabular foundation models: numbers, natively

The alternative is a different class of model entirely. Instead of being primarily trained for language, tabular foundation models are designed to work directly with rows, columns, and numeric distributions — the actual structure of the data. Neuralk.AI presents Seldon as a tabular foundation model for industrial tabular classification, with a scikit-learn-compatible interface. That makes it relevant to structured classification workflows, but it does not by itself establish that Seldon performs demand forecasting, pricing optimisation, or fraud detection.

The projection that tabular foundation models could become a core predictive layer for enterprise operations by around 2030 comes from Alexandre Pasquiou, as cited by The Neuron. It is a projection, not an established industry forecast. The underlying case is understandable: enterprise data remains heavily tabular, appearing in CRMs, ERPs, insurance portfolios, and logistics systems. But each proposed use still needs task-specific validation, and no model category automatically guarantees better results.

The hybrid: LLMs as the face, predictive tools as the engine

The practical hybrid approach does not require an LLM to perform the numerical work itself. An LLM can act as a natural-language interface, translate a request into a structured query, and call an external analytics or predictive tool. The tool then performs the calculation or prediction, while the LLM explains the result and helps the user inspect it. This preserves the chat experience without treating fluent language as proof of accurate forecasting.

This is the architecture we would consider for production — and at ai-jarvis.eu, we live this split daily. In our own pipelines, LLMs summarize, transcribe, and draft. They do not forecast our traffic or predict load on the AI Arena benchmark rig (the RTX 5060 Ti 16 GB and friends), because no benchmark we run there — tokens per second, time-to-first-token, VRAM usage — measures whether a model can predict anything. Those numbers tell you speed, not foresight.

The European angle: the AI Act makes validation more important

For European companies, this is no longer just an architecture debate; it can also be a compliance question. The EU AI Act is being applied in stages. As of 2 August 2026, the Act's relevant Article 50 transparency obligations apply to covered AI systems and their providers or deployers. Those requirements should not be conflated with the separate obligations for high-risk AI systems, whose applicability depends on the system, its use and the relevant transition timetable, including later obligations for some categories. The European Commission's regulatory framework sets out the broader schedule.

Many classic tabular prediction jobs — including some credit, insurance and employment-related uses — may fall within the Act's high-risk categories, but not every spreadsheet forecast does. If a European bank uses an AI system to score loan applicants, the applicable classification, documentation, human oversight, data governance and accuracy requirements need to be assessed for that specific use. A general-purpose text model producing an opaque or poorly validated recommendation can be difficult to defend. A structured model with explicit inputs, documented evaluation and auditable outputs may provide a more suitable technical basis, but it does not automatically remove regulatory duties.

GDPR compliance also does not follow simply from choosing a tabular model or EU-hosted infrastructure. Organisations still need an appropriate legal basis, security measures, data minimisation and other safeguards. European infrastructure and specialised models can support a data-residency strategy, but they are not a substitute for a proper compliance assessment.

This is also where Europe's AI strategy is looking beyond a single race to train the largest general-purpose model. Specialised models, sovereign infrastructure and data governance are important parts of the European discussion. Tabular prediction models, including work by French startups such as Neuralk.AI, fit that specialised direction more naturally than asking another chatbot to act as a forecasting system.

The practical takeaway

For developers and companies, the rule is simple: match the model to the job. Use LLMs for what they are excellent at — summarizing, extracting, explaining, generating and orchestrating tool calls. For structured prediction, use statistical or machine-learning systems trained and validated for structured data, and let the LLM sit on top as the interface where useful. Before you buy “AI forecasting”, demand validation on your own historical data. Run the model against the last six months and measure the real forecast error. If the vendor only shows you demo charts, you know why.

ChatGPT can help explain what your data says and can call tools that estimate what may come next. It is not, by itself, a substitute for validated statistical or machine-learning forecasting on structured data. The useful direction is not replacing LLMs, but assigning numerical prediction to the system that can demonstrate it has been tested for that task.