The portco has made the decision. Oversight is required. Legal has briefed the board, and the CFO has approved the engineering budget. The question is no longer whether to build. It is what to build, in what order, in a company where AI is already in production and the compliance architecture came after the model.
That is the realistic starting point for most retrofits. Not greenfield. The model is running. Decisions are being made. The build has to wrap what already exists without stopping production.
Here is what the build actually looks like.
Before sequencing specific components, the operating context matters. A greenfield deployment can design compliance in from the start. A retrofit has constraints: a production model that cannot go offline, existing data pipelines that feed it, and engineering teams who built the original system and will need to extend it.
In a retrofit, the sequencing rule is: start with what the auditor asks for first. In regulated-industry audits, the first request is a decision trace for a specific output. Not a policy document. Not an architecture diagram. A trace: what did the model see, what did it produce, what happened after.
That means the audit trail is the first thing to build. Human-in-the-loop gates come second, because they are part of the trace. The decision-logging schema is what defines both. And vendor assessment is the piece that closes the gap on what you cannot control directly.
Component 1: Audit trail architecture
The audit trail is not application logging. Application logs are designed for debugging. They capture errors, exceptions, and operational events. They are searchable by teams who know where to look. An audit trail is something different: a structured, append-only record of every decision event that the model contributed to, written at inference time, not reconstructed afterward.
The design requirement is immutability. Audit records cannot be modified once written. They are not a database table that someone might UPDATE to clean up a bad output. They are an append-only log, ideally written to a service where deletion requires explicit administrative action that itself gets recorded. This is a design choice, not a default. Most application databases are mutable. Choosing append-only storage for audit records is a deliberate architectural decision.
What goes into the record depends on the decision type, but the pattern is consistent: the full input set the model received (not a hash, not a reference, the actual data), the model version and configuration that processed it, the output and its confidence or probability, the rule or threshold that translated the output into an action, and the final disposition of the decision. If the model flagged a claim for review and a human cleared it, all of that is in the record. The human step is part of the trace, not an annotation added later.
Retention follows the compliance surface. For decisions that touch consumer credit or healthcare, the standard is years, not months. The record has to survive the engagement so it can answer questions long after the model has been updated.
The implementation sits at the inference layer, not upstream. The record is written when the inference call completes, before the downstream action fires. That placement is what makes the trace complete. A record written by the downstream application might miss cases where the application encountered an error. A record written at inference misses nothing.
Component 2: Human-in-the-loop gate placement
The question most teams get wrong is which decisions need a human gate. The instinct is to add gates broadly. That creates volume the review team cannot handle and defeats the purpose of deploying AI at all.
The placement rule is more precise. Gate the decision that reaches a customer or a regulator. Not every intermediate model call. Not every confidence flag. The gate sits at the point where the model output becomes a commitment: the prior authorization that a nurse issues, the credit limit that a loan officer approves, the routing decision that determines what a patient does next.
A healthcare payer processing tens of thousands of prior-authorization decisions per day cannot add a human reviewer to every model call. What they can do is add a final-approval step for the class of decisions that fall outside the model's confidence bounds, and for the decision types that payer contracts require human sign-off on. A nurse reviews those. The rest process automatically, with the full trace written to the audit log.
The gate is substantive, not nominal. A human reviewer clicking approve on a binary without seeing decision context does not satisfy the oversight requirement. The review interface has to present the same decision trace that would go to an auditor: the input, the model output, the confidence level, and the action the system would take. The reviewer sees what the model saw. Their decision, including any override, becomes a node in the audit record.
Component 3: Decision-logging schema
The schema is where the architecture becomes concrete. A portco engineer building the audit trail needs to know exactly what fields the record contains.
The required fields, in the order a reviewer encounters them:
- •
input_payload: The full data the model received. Not a reference to another table. The actual payload, serialized. - •
model_idandmodel_version: Which model and which deployed version. When a vendor updates their model, this field is how you establish what was running when. - •
inference_timestamp: UTC, millisecond precision. When the call was made, not when the decision was recorded. - •
output_payload: The model's full output. - •
confidence_score: The probability or score the model attached to its output, where the model makes this available. - •
applied_rule: The business rule or threshold that converted the model output into an action. "Confidence above 0.87 routes to auto-approval" is a rule. It should be in the schema, not inferred from code. - •
action_taken: What the system did: approved, denied, escalated, routed. - •
human_reviewer_id: The identifier of the human who reviewed the decision, if any. Null if no human review occurred. - •
review_timestamp: When the human review completed. - •
override_taken: Boolean. Did the reviewer override the model's recommendation? - •
override_reason: Free text if override was taken. Required field when override is true. - •
outcome: The final disposition of the underlying transaction or case, populated after resolution.
This schema is not a suggestion. It is the minimum that an auditor in a regulated-industry engagement will ask to see. Fields missing from the schema are fields you cannot produce on request.
Component 4: Vendor assessment checklist
A portco that built its own model controls the schema above. Most portcos did not build their own model. They are using a foundation model from a vendor, often with a thin application layer over the vendor's API. The vendor's opacity becomes the portco's compliance risk.
The assessment checklist covers four areas.
GPAI documentation. Under the EU AI Act, Art. 53 obligations for general-purpose AI model providers have applied since 2 August 2025. Two artifacts matter when assessing a vendor. Under Art. 53(1)(b), the provider owes documentation to downstream providers of AI systems who intend to integrate the general-purpose AI model into their own product. The content of that documentation is specified by Annex XII and covers the model's capabilities and limitations. A portco that builds an application layer over a vendor's API is itself a provider of an AI system, and that is what gives it this statutory lever. A portco that only uses a finished AI system without integrating the underlying model is a deployer under Art. 3(4) and must rely on contractual rights instead. Under Art. 53(1)(d), providers must publicly publish a sufficiently detailed summary of their training content using a template provided by the AI Office; that summary can be verified without contacting the vendor directly. The Annex XI technical documentation, which covers training data and architecture in detail, goes to the AI Office and national competent authorities on request and is not public. When assessing a vendor, require the Annex XII documentation under Art. 53(1)(b) and confirm the public training summary is published on the vendor's site. One additional consideration: models placed on the market before 2 August 2025 have a conformance deadline of 2 August 2027, so check whether your incumbent vendor's model predates that cutoff.
Traceability of outputs. The model needs to return not just an output but the information the portco needs to populate the schema above. Some vendors expose this natively. Others do not. Output traceability is a vendor selection criterion, not an afterthought.
Contractual audit rights. The portco's contract with the vendor should include the right to audit the vendor's compliance with their disclosed documentation. This is not standard in off-the-shelf API terms. It requires explicit negotiation. Without this right, the portco has no mechanism to verify that what the vendor documented matches what the vendor deployed.
Change notification. Vendors update models. A model that passes compliance review today may be a different version next month. The contract should require the vendor to notify the portco before making any change to the model version underlying a production deployment, with sufficient lead time for the portco to re-validate. Without this clause, the vendor can swap the model and the portco's audit records will reference a model version that no longer matches the production behavior they are logging.
The 90-day build sequence
For a portco already running AI in production, the first 30 days go to the audit trail architecture and the decision-logging schema. These two components have to be designed together because the schema defines what the trail captures. Engineering builds the append-only log and instruments the inference layer to write to it. By day 30, every new inference event has a complete record.
Days 31 through 60 focus on the human-in-the-loop gates. The audit trail is now running. Adding the human review step means extending the trail to capture reviewer decisions and integrating the review interface with the audit log. The gate placement decision happens in week five, before the interface is built. It is a business decision, not an engineering one: which decision classes require human sign-off, and at what volume can the review team operate.
Days 61 through 90 go to vendor assessment. By now the portco has a defined schema and knows exactly what data the vendor model needs to produce to populate it. That specificity drives the vendor conversation. The portco can evaluate whether the current vendor meets the traceability requirement, and if not, what the migration path looks like.
What waits past 90 days: the audit on historical decisions made before the trail was instrumented. That backfill is real work, but it is bounded work. The compliance exposure is the period before the trail was live. Once the trail is running, new exposure does not accumulate.
If you want to assess where your portco's AI deployments stand against this build spec, our compliance readiness assessment maps each production deployment against the four components above and delivers a prioritized remediation roadmap. For portcos addressing data platform needs alongside the compliance build, we run both in a single engagement. It is the right starting point before the 90-day build begins.