Automated Pricing Needs Competition Safeguards

Your software supplier offers a setting that will adjust prices automatically. It sounds like a way to respond faster to demand and reduce manual work. Before enabling it, ask a less glamorous question: what information and incentives will shape those prices, and can your business explain the resulting decisions?

Pricing automation is not automatically improper, and a manual approval button is not automatically protective. The system needs a documented business purpose, understood data sources, independent decision authority, and specialist legal review appropriate to its market and jurisdiction. This is an operating-design discussion, not a legal determination about your business.

Start with the information, not the algorithm label

A tool may use your own costs, available capacity, historic transactions, publicly observable information, third-party datasets, or pooled customer data. Those categories have different implications. A vendor describing its output as AI does not answer what information is shared, how it is transformed, or which parties benefit.

Request a data-flow diagram and a written account of inputs, recipients, retention, updates, and customer-to-customer information sharing. If a supplier will not explain a material source, treat it as an unresolved procurement issue. Do not assume that aggregated or anonymized data is automatically suitable for every pricing purpose.

Conventional price rules can also produce harmful outcomes. A language model is not necessary for a poor objective, an inappropriate input, or an uncontrolled price change.

Read cases carefully instead of turning them into slogans

The DOJ's RealPage announcement describes a proposed November 2025 resolution concerning competitively sensitive information and pricing alignment. It is a useful reason to ask detailed vendor questions, not evidence that every pricing system has the same behavior.

The official case document index, reviewed for this draft, labels the RealPage document as a proposed final judgment and separately lists a March 2026 final judgment for Greystar. A complaint, proposed remedy, entered judgment, and research simulation establish different things. This article does not infer the full current docket from one index or pronounce a universal legal test.

Have qualified counsel evaluate the actual arrangement. The practical lesson is to understand your system before relying on a marketing assurance that its recommendations are independent or objective.

Work through an equipment-rental proposal

Consider an illustrative equipment-rental company deciding how to price its own available machines. Its commercial manager owns the pricing policy. The rental system owns confirmed availability, maintenance exclusions, and the accepted customer contract. The finance system supplies approved internal cost information.

An analyst builds a proposal using the company's own utilization history and documented commercial constraints. AI may help explain patterns or identify anomalies; a conventional pricing engine applies approved rules. Initial recommendations stay in a review workspace rather than publishing directly.

Suppose a vendor feature introduces a pooled forecast built from other operators' nonpublic information. The workflow pauses that feature for procurement and legal review. Staff do not treat the label market intelligence as sufficient evidence of acceptability.

The commercial manager can approve a supported proposal within existing authority. A recommendation involving an unusual source, unexplained coordinated movement, or a policy exception goes to the appropriate specialist. The system records the accepted rate, its effective period, and the underlying reason in the rental record.

Design oversight that changes the outcome

Review must be capable of rejecting a recommendation and disabling the relevant function. Showing a staff member a price with an accept button is not meaningful oversight if the staff member cannot inspect the basis or take another path.

Keep a clear distinction between suggested, approved, published, and contracted prices. When a tool changes versions or starts using a new data source, decide whether its previous evaluation still applies. Monitor outcomes against the business objective and investigate unexplained behavior.

Do not let a model decide what counts as a legal exception or exchange sensitive information with another seller's agent. Independent decision-making and lawful information use require explicit organizational arrangements, not a polite instruction inside a prompt.

Prepare the fallback before launch. Disabling recommendations should return the business to an approved pricing process, not silently rewrite accepted contracts or quotes. Record when the function was paused, which unaccepted proposals need review, and who will reconcile customer-facing prices. Have the relevant commercial and legal owners determine how existing commitments are handled.

Use a concrete vendor review brief

Before launch, document the questions that matter for this pricing process.

• Which inputs are used, who owns them, and what rights permit this use?
• Does any data or recommendation move between competing businesses?
• What objective is optimized, and which constraints cannot be traded away?
• Who may change the model, input sources, or publishing rules?
• What triggers a pause, specialist review, or rollback?
• Can the business reconstruct why a particular customer received a price?

Test unusual cases: a stale availability feed, an exceptional demand spike, an incorrect internal cost, and a price change after a customer has accepted terms. Verify the customer-facing record rather than only the recommendation screen.

A useful pricing system makes commercial decisions more explainable and manageable. If automation hides their basis, its apparent efficiency can create a much larger operating problem.