What a Decision Record for AI Integration Needs to Survive Audits

A decision record for an AI integration survives an audit when it carries five fields, each doing a distinct job.

The worksheet approach used for AI benefit testing is a good model here. It keeps baseline measurement, review and rework, running cost, and dependencies as separate blocks, and it labels estimates as estimates. It also ends with an explicit question: include the assumption, carry a sensitivity range, or exclude it, and who decides what evidence would change the conclusion (Proactive Logic). A maintenance record should answer that question in writing for each major input.

The owner field is the one teams skip most often. A record held by "the platform team" has no owner. Name a person who can be asked, months later, why the figure was set where it was set. If that person has left, the source column should be good enough that the new owner can reconstruct the reasoning.

Write the decision in one sentence and make it falsifiable. "We will budget a fixed recurring maintenance figure for the customer-facing assistant integration, reviewed before the next model provider contract renewal." That sentence tells a reader what was chosen, what it applies to, and when it will be revisited.

A decision that only says "estimated maintenance spend for the AI integration" cannot be audited, because a reader cannot tell what was approved, by whom, or at what level of precision. Precision matters: is the number a budget cap, a planning figure, or a forecast? Auditors ask this, and so do finance teams.

Capture the date the decision was made and the date the record was last edited, as separate fields. The Intent Ledger guidance recommends snapshotting web pages at the moment of capture, so a later reviewer can verify that unchanged evidence still says what the record claims it says (The Intent Ledger). For an AI integration, that means saving the vendor pricing page, the API documentation page and any internal dashboard export as of the estimate date. Pages change. A saved copy is the evidence.

Keep the record somewhere versioned, such as a repository alongside the integration code, so changes are visible as diffs rather than invisible overwrites. The same guidance suggests versioning assumptions separately, so a correction never erases the original reasoning.

Assumptions are where maintenance estimates break. Work through the cost stack systematically and give each line a source, a date and a label.

A credible structure follows five cost categories: data and infrastructure, model development or licensing, compute and cloud resources, integration and change management, and ongoing operations (itsvalue.com). For maintenance specifically, the third and fifth categories carry most of the weight, because inference cost scales with usage and ongoing operations includes monitoring, retraining, model versioning, security reviews and compliance audits.

Then confront the change rate. A study of API integrations found that 41 percent of APIs experience schema drift within 30 days, rising to 63 percent within 90 days, and that field additions account for 86 percent of drift events (dev.to). That figure directly sets a maintenance assumption: how many hours per month will you spend adapting to schema changes on five external endpoints? If the record says "low" without naming the drift rate it assumed and where that rate came from, a reviewer has nothing to test.

MCP security guidance gives another assumption worth recording. A survey in that whitepaper found nearly 7,000 internet-exposed MCP servers, roughly half without authentication, and it reports multiple incidents including cross-tenant data exposure and prompt injection attacks against a code hosting MCP server (Cloud Security Alliance). If your integration uses MCP servers, the maintenance estimate should assume ongoing patch and audit work, sourced to whatever vulnerability or incident log you actually track.

Record the assumption the way a reviewer can use it:

Assumption A3: API schema changes on the 5 external endpoints
Label: assumed (not measured on our traffic)
Basis: 41% of APIs drift within 30 days (dev.to summary of KushoAI report, read on 2026-02-01, saved copy in /records/2026-02-01/drift.pdf)
Effect: adds 6 to 10 hours per month of adaptation work
Confidence: medium. Would change if our own 90-day drift log shows fewer than 2 breaking changes.

That block answers where the number came from, what type of claim it is, how uncertain it is, and what would overturn it. A reviewer can check the saved copy, read the saved source, and decide whether the assumption still holds.

Two categories of change make AI integration estimates go stale faster than ordinary software.

The first is API and tool drift. Because schema drift is the second most common API failure category after authentication failures, at 22 percent of failures versus 34 percent for auth (dev.to), maintenance work should be modeled around detection, not just repair. If your monitoring only catches drift when a customer reports a bug, the maintenance estimate should say so, because that assumption drives both cost and risk.

The second is model and provider change. Treat any provider-side model change as a trigger, not a calendar event. When a model version changes, tool-calling behavior, token pricing and reliability can shift together, and the maintenance estimate built on the old behavior needs re-testing.

Authorization is a third moving part worth recording explicitly. MCP authorization relies on OAuth 2.1 with protected resource metadata discovery, and the implementation detail matters for maintenance work, because token lifetimes, scope definitions and discovery endpoints are configuration your team must keep current as clients and providers evolve (MCP documentation). Scope design changes, such as adding a new write scope, change the security review burden, and that burden belongs in the maintenance estimate. A practitioner guide on MCP OAuth notes that access tokens are often configured in a range from 300 seconds to 3,600 seconds and refresh tokens from 300 to 86,400 seconds (Scalekit). If your integration's token handling depends on a provider change, the record should say which configuration was assumed.

Here is a record that would pass a later review. It is short, but every claim is checkable.

Decision: Approve a recurring maintenance figure of a defined monthly amount, in US dollars, for the sales assistant integration, for a 12-month period.

Scope: Five external API integrations, one MCP server for internal document retrieval, one hosted model provider.

Assumptions: A1 (measured): current monthly engineering hours spent on fixes, from the ticket export saved on the decision date. Source: internal tracker export, saved copy attached. A2 (assumed): drift rate on the five external APIs, based on the 41 percent within 30 days figure, saved copy attached. Effect: 6 to 10 hours per month. A3 (assumed): one model provider change per quarter, each requiring regression testing. Source: vendor changelog history saved on the decision date. A4 (calculated): total hours multiplied by the blended hourly rate from finance, with the rate source and date noted.

Owner: named engineer, with a named deputy.

Review date: fixed calendar date, or earlier if any trigger fires.

Triggers: a model version change from the provider; a breaking API schema change on any of the five endpoints; a security advisory affecting the MCP server or its authorization configuration; monthly spend crossing a stated threshold.

Now the version that fails:

"The AI integration will need roughly a day a month of maintenance. Approved. Owner: the AI team."

Why it fails, line by line. "Roughly a day" has no source, no label and no range, so a reviewer cannot tell whether it is measured or guessed. There is no date, so nobody knows whether it describes current usage or a launch-week snapshot. "The AI team" is not a person, so the question "who decided this and will defend it" has no answer. There is no review date, so an old figure can silently outlive the system it described. And there are no triggers, so a model change or a breaking schema change would not prompt anyone to revisit it.

The gap between the two records is about 30 minutes of writing. The practical return is that a later reviewer can answer the same five questions a source-backed workflow must answer: where each number came from, whether it is a fact, calculation or assumption, who approved it, what changed between versions, and what remains unresolved with an owner for the next action (The Intent Ledger).

A review date is necessary but not sufficient. Calendar-only reviews fail because the thing that invalidates an estimate usually happens between reviews.

Build a small trigger list into the record and wire it to something that actually fires. Observability practice helps here: good integration logs carry a timestamp, a severity level and context, and they are written for triggers, errors and completions rather than every loop iteration (Prismatic). The same principle applies to the record's triggers. You do not need an alert on everything; you need an alert on the events that would change the estimate.

A practical trigger list for an AI integration:

Health checks and monitoring tools are the natural place to anchor these. API performance monitoring guidance emphasizes that performance problems affect user trust long before alerts fire, which is the same argument for drift monitors: waiting for a customer report is the most expensive way to learn something changed (LogicMonitor).

When a trigger fires, do not just update the number. Add a short note saying which assumption changed, what new source you used, and whether the decision still stands. That gives the next reader a chain of reasoning rather than a single unexplained figure.

Five failures account for most records that collapse under review.

The unlabeled guess. A drift rate or rework percentage appears with no label. Fix: mark every input as measured, calculated or assumed, and add a confidence note.

The orphaned owner. The owner is a team, a committee or a role that has been reorganized. Fix: name a person and a deputy, and record ownership transfers with dates.

The stale source. A vendor pricing page or documentation page is cited by URL only. Fix: save a dated copy alongside the record and cite the saved copy.

The missing downside. The estimate shows only the expected case. Fix: carry a sensitivity range and state what evidence would move you out of it, as the AI benefit worksheet requires (Proactive Logic).

The silent revision. Someone updates the number without a note. Fix: version the record and require a one-line change reason.

If you are standardizing this across several integrations, a shared template and a review cadence do most of the work. One team pattern is to review open questions weekly on active projects and monthly during quiet periods, assigning each unresolved item an owner and a review date so the backlog does not grow (The Intent Ledger). That cadence maps cleanly onto a portfolio of AI integrations.

For teams running several models and providers behind one interface, consolidating inference through a single API key simplifies the maintenance estimate itself, because one provider relationship replaces many. Quanta Inference exposes text, image, video, audio and embedding models through one OpenAI-compatible endpoint, which reduces the number of vendor change triggers a record has to track. If you want help deciding which integrations need full passage-level records and which need only a short note, a free 30-minute discovery call can scope that.