McDonald's AI pricing incident raises questions about evidence and high-risk thresholds

What allegedly happened

On 28 January 2025, an antitrust lawsuit was filed in the United States District Court for the Northern District of Illinois, alleging that McDonald's Corporation used an AI pricing engine to coordinate menu prices across multiple restaurants ^[1]. The complaint claims the system was trained on confidential sales data pooled from participating restaurants and that it output pricing recommendations that led to higher menu prices than would have resulted from independent pricing decisions ^[2].

The case has been added to the AI Incident Database as Incident 1729 ^[3]. The incident is alleged, not proven, but it illustrates a recurring problem: when an AI system influences decisions that affect people or markets, the operator may later need to show what the system did, what it learned from and how it arrived at a particular output.

The evidence question

If the allegations are tested, several evidence questions arise. First, what data did the AI use? Training data for a pricing model could include historical sales, competitor prices, weather, footfall and promotional calendars. If the model learned from pooled data shared by multiple operators, proving which data went in becomes harder unless manifests or snapshots were kept and sealed when training began.

Second, how were pricing decisions made? If the AI recommended prices and a person approved them, logs of those recommendations and approvals would matter. If the system set prices automatically, the question is whether it logged each decision and whether those logs can be shown unchanged.

Third, who had access to the logs? A log kept by the same organisation that ran the system is easier to challenge than one with an independent check.

None of this answers whether the alleged conduct violated competition law. That is for the court. The point here is narrower: in a dispute, the side without its own records starts on the back foot.

Does it count as high-risk AI?

The AI Act defines high-risk AI systems in Article 6 and lists them in Annex III ^[4]. Point 5(b) covers AI used to evaluate creditworthiness or set prices for life and health insurance for natural persons ^[5]. Menu pricing at a fast-food chain does not fit that category cleanly, because it affects customers as consumers, not as applicants for credit or insurance.

However, if the system's role extended to processing personal data about purchasing patterns, frequency or spending in a way that influenced individual pricing or offers, it might edge closer. The line is not settled. The broader question is whether the system made decisions with significant effects on people, which is the threshold the regulation uses.

If an AI system does fall under Annex III, high-risk requirements apply from 2 December 2027 ^[6]. Those include automatic logging of events under Article 12, data governance under Article 10, technical documentation, human oversight and quality management.

What this means for you

If you deploy an AI system that influences pricing, credit decisions, hiring or other areas listed in Annex III, ask now:

• Can you show what data the model was trained on, and when that data set was frozen?
• Can you document each pricing recommendation or decision the AI made, and who approved it?
• Can you prove that those records have not changed since they were created?
• Does your system log events automatically, and are those logs protected against tampering or deletion?

These questions matter whether or not your system is high-risk under the AI Act. In a dispute, the organisation that kept clear records has an easier conversation than the one that did not.

How a digital witness helps with AI pricing logs

Here, the things to seal are the pricing decisions as they are made: the input data reference, the model version, the recommended price and the timestamp. If a person approves the recommendation, that approval gets sealed too.

Sealing takes a fingerprint of the record, not the record itself, so pricing data never leaves your systems. The fingerprint is sent to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back ^[7]. Anyone you share the record with later can calculate the fingerprint again and check it against the sealed one. If it matches, the record has not changed. Change a single character and it will not match.

A digital witness shows that the record existed at a certain time and has not been altered since. It does not show that the pricing decision was lawful, fair or compliant with competition rules. Those are separate questions, and logs alone do not answer them.

How it would work

1. Your pricing system writes each decision to a log: date, time, item, model version, recommendation and approver.
2. A fingerprint of that log entry is sent to WitniumChain and sealed.
3. If the decision is questioned months later, you share the log entry and the witness ID. The recipient calculates the fingerprint and checks it. If it matches, the record has not changed since it was sealed.

The first 2,000 witnesses a month are free. Documentation is at witniumchain.com/docs ^[8].

What to watch

• 2 December 2027: high-risk requirements under Annex III of the AI Act apply, including automatic logging (Article 12) and data governance (Article 10).
• 2 August 2028: high-risk requirements under Annex I apply.
• Guidance from the AI Office on how pricing systems are classified under the regulation.