> ## Content Index > Fetch the complete content index at: https://nextwith.ai/llms.txt > Use this file to discover other available public pages before exploring further. # McDonald's AI pricing dispute: recommendations still need an audit trail - URL: https://nextwith.ai/mcdonalds-ai-pricing-dispute-recommendations-still-need-an-audit-trail/ - Published: 2026-10-11T13:06:13.000Z - Updated: 2026-10-11T13:06:13.000Z - Description: McDonald’s denies its pricing tool sets prices. A lawsuit alleges otherwise. The dispute offers a concrete question for pricing teams: who accepts a recommendation, and what does the system record? - Author: NextWith.ai Editorial Desk - Tags: Business, News McDonald’s AI pricing dispute puts a practical deployment question in focus: where does a recommendation end and a customer-facing decision begin? Those are different steps, and a claim that a person makes the final decision leaves room for further questions about how that decision is made. [CNBC’s October 11 report](https://www.cnbc.com/2026/10/11/ai-dynamic-pricing-shoppers-groceries.html?ref=nextwith.ai) describes a federal antitrust lawsuit alleging that McDonald’s used an AI pricing engine to set U.S. menu prices and overcharge customers. This article does not independently inspect the court filing or establish whether the allegation is true. A lawsuit allegation is not a court finding. In its statement, reproduced in [AI Incident Database report 8046](https://incidentdatabase.ai/reports/8046/?ref=nextwith.ai), McDonald’s says its tool offers restaurant-specific recommendations. It denies that AI sets menu prices, personalizes prices to individuals or changes them in real time. The company says franchisees independently choose prices and can decline its recommendations. This is the company’s account, not an independent assessment of the software. ## Analysis: identify the actual decision Our analysis starts with the distinction between suggesting a value and applying it. An operator evaluating a pricing tool could draw a simple sequence: information enters the system, the software proposes a price, an authorized person accepts or rejects it, and another step publishes the approved amount. The question is whether the implementation preserves those boundaries. A useful record would connect a recommendation to a specific restaurant, item and time. It would identify the proposed amount, the person authorized to decide, their decision and the amount subsequently displayed. This is a proposed verification method. We have not tested McDonald’s system and do not claim that it produces such a record. The record matters because an approval button alone does not explain a decision. A reviewer would also want to know whether the person can change the proposal, reject it or delay it, and whether another process can apply it anyway. A narrow test could follow one suggestion from creation to display and compare each action with the operator’s documented authority. ## Separate three kinds of change For a deployment review, we would ask three different questions. Does the system recommend a price for a restaurant? Can it automatically change the displayed price when conditions change? Can it present different prices to individual customers? Answering one question does not answer the other two. The vendor’s description and the system’s observed behavior should be recorded separately. A hypothetical test could use an isolated restaurant account and synthetic transactions. Reviewers could change a permitted input, inspect the resulting suggestion and decline it. They could then check whether the published price remained unchanged. If the application still changes the price, the team would have a specific boundary failure to investigate rather than a vague disagreement over the word “AI.” Another proposed test would inspect the path by which a recommendation reaches a menu or checkout. A team could verify that the displayed amount matches the approved version and that a rejected or superseded proposal cannot be applied later. This checks execution after the decision. It does not establish whether the recommendation itself is commercially appropriate or legally permissible. ## Document inputs as well as outputs The same review should list which information the recommendation receives and at what level it describes the customer or restaurant. For example, an evaluation plan could distinguish synthetic restaurant-level conditions from synthetic individual profiles. Reviewers should not infer individual targeting merely because software uses data, or infer its absence merely because a human accepts the result. That input inventory would make the vendor’s claims testable. The team could compare the documented scope with the actual fields supplied to the model, the stored recommendation and the approval record. Missing evidence should remain an unresolved question. It should not be converted into either reassurance or an accusation that a particular deployment uses personalized pricing. These proposed fields map directly to the contested boundary: the suggestion records what the software recommends, the approval records the franchisee’s decision, and the display record shows what was actually charged. The McDonald’s dispute remains contested. A human decision step does not by itself resolve an antitrust allegation, and we make no legal judgment here. Our practical conclusion is narrower: pricing teams need evidence of the relationship between inputs, recommendations, authorization and the final displayed amount. That is a more useful acceptance criterion than whether a product is marketed as an AI tool. Before deploying a pricing tool, document the data it receives, who accepts its suggestions and how an approved price reaches the customer.