A model approval needs role separation and an identity-tied audit trail in proportion to what the approved model can get wrong, and who it can harm. That evidence is an engineering output, not a policy document: a named reviewer, a recorded decision, a timestamp and a snapshot of what was approved, produced by the pipeline so that a non-engineer can read it and sign against it. A two- or three-person team can meet the bar with documented, genuinely independent compensating controls that leave a dated trace. Electronic records that fall under FDA’s 21 CFR Part 11 need unique user IDs, signatures bound to the record and an audit trail that someone reviews on a schedule.
Matching approval depth to the model’s risk tier
Approval depth should follow the decision the model feeds, not the size of the organisation. Corporate.ai’s enterprise model governance guide lists the factors that set a tier: decision impact (access to jobs, credit, health care, housing or legal standing), degree of autonomy, data sensitivity, audience, reversibility and scale, and regulatory exposure. The same guide holds that three or four tiers is usually enough, with review depth, approval authority and monitoring frequency rising at each level. SR 11-7 makes the same point for banks: a community bank with a few moderately complex models may apply the guidance far less elaborately than a larger bank, while models with a material impact on business decisions need a more extensive and rigorous framework.
| Situation | Role separation | Enforcement | Evidence an auditor can test |
|---|---|---|---|
| Two or three people, modest stakes | Owner or advisor approves; the developer never approves their own release | Documented sign-off plus independent review after the fact | Dated sign-off and an initialled review record |
| Higher-risk tier, such as a model feeding a regulated decision | Independent validator who did not build the model | Pre-production gate that reviews validation evidence and sets conditions | Validation evidence, recorded conditions, named owner and review date |
| Several teams on shared infrastructure | Per-team deploy roles granted through role bindings | Kubernetes RBAC plus an admission gate that rejects objects failing policy | Identity-tied API audit log, no shared accounts |
| Regulated electronic records under Part 11 | Originator cannot approve; QA independent | Validated workflow with electronic signatures | Signatures showing name, date and time, and meaning; tamper-evident trail; documented reviews |
Separating the engineer who deploys from the person who approves
Role separation for a model release means the person who builds a model version does not approve their own work, and the building team is never the only approver. For a very small team, process carries that separation (a sign-off record plus independent review); as team size and regulatory scrutiny grow, the platform has to enforce it through RBAC, an admission gate and a tamper-evident trail.
Can two or three people show credible role separation, or will a reviewer expect system gating?
Two or three people can show credible role separation, provided the controls are documented, consistently applied and genuinely independent. Avenlor Consulting’s guidance for small finance teams describes the workable pattern: use the owner or a manager as the second pair of hands, limited to authorisation and independent review, so the owner acts as a control rather than a bottleneck. Translated to model release, the engineer trains and packages the model, an advisor or owner approves promotion without ever editing the pipeline, and someone outside the release path reviews the deploy log each month.
Where one person really must do two jobs, the strongest cheap compensating control is a senior review after the fact, line by line, initialled and dated. SG Systems’ approval-workflow guidance adds the rule for small sites: define controlled substitutes and escalation rules, and record who stepped in, why and for how long. The test is whether you could prove six months later that the control operated, because “the advisor reviews releases” is a claim while a dated, signed record is a control an auditor can test.
Checklist separation has a quiet failure mode: the same person ends up filling both roles and nobody independent notices. We would expect a reviewer to ask for system enforcement once the model feeds a regulated decision, runs unattended or sits on infrastructure shared by several teams, since that is where a checklist cannot show that nothing bypassed it. Avenlor’s guidance notes that in accounting systems, role-based access and approval workflows cost little beyond the discipline to configure them, and an auditor can see they are switched on. Why one audit-trail design does not fit every need is covered in our piece on segregating duties across different audit-trail needs.
Independence the way SR 11-7 judges it
SR 11-7 says validation should generally be done by people who are not responsible for development or use and have no stake in whether the model is found valid. The guidance frames the goal as “effective challenge”: critical analysis by objective, informed parties, which depends on incentives, competence and influence. Independence is judged by actions and outcomes rather than by reporting lines alone, and validation work done by developers is acceptable only when an independent party critically reviews it. Validation staff need explicit authority to challenge developers and escalate findings, and SR 11-7 notes that this influence can be shown by actual instances of models being changed as a result of validation. For an approval trail, that means recording the challenges raised and what changed because of them, not only the final approval. Corporate.ai’s guide puts the risk plainly: a team asked to approve its own work will tend to find that the work is fine.
How do we split deploy permissions so nobody can push a model that skipped the approver’s sign-off?
Deploy permissions split cleanly in two layers: RBAC decides who may act on the cluster, and an admission gate decides whether the object they submit is acceptable. In Kubernetes, a Role or ClusterRole holds purely additive permissions, and a RoleBinding grants them to users, groups or service accounts within one namespace, while a ClusterRoleBinding grants them cluster-wide. A per-team design applies least privilege, granting only the specific resources and verbs each workload needs.
The RBAC API itself blocks privilege escalation: a user can create or update a role binding only if they already hold the referenced role’s permissions or have the bind verb on it, and can create or update a role only with matching permissions or the escalate verb. A binding’s roleRef is immutable, so someone can be allowed to manage a binding’s subjects without being able to change which role it grants.
RBAC cannot tell an approved model from an unapproved one, which is why the second layer exists. Admission controllers run after authentication and authorisation and before the object is persisted to etcd, and validating webhooks inspect the final object and either accept or reject it. SG Systems describes the paper-world equivalent as evidence prerequisites: the “Approve” button appears only once the required attachments are present, which prevents “approve now, evidence later”. In the design described here, a validating policy plays that role for model release by admitting a model image or reference only when the registry shows a recorded approval for that exact version.
The MLflow Model Registry can hold the record the gate reads: model versions carry tags such as validation_status:pending, and aliases such as @champion promote models in a controlled, auditable way. Admission policies themselves belong in a GitOps workflow, which gives every policy change versioning, peer review and an audit trail. When the gate denies a request, Kubernetes audit logs record which controller rejected it and why. The price is maintenance: a slow webhook adds latency to every matching API request, so webhook latency needs monitoring and aggressive timeouts.
Who deployed which model version, and when, under whose name?
Part 11 requires records and audit trails to be uniquely attributable to a specific individual and prohibits shared accounts, and GoValidation’s Part 11 checklist calls generic or departmental accounts a citable finding regardless of other controls. Kubernetes leaves the username format to the cluster administrator’s authentication configuration, so tying API audit entries to people is a decision made in the identity setup. A sound design lets a pipeline service account execute the deploy while the trigger and the approval carry the named human who authorised them. The W3C PROV data model has the vocabulary for exactly this: delegation assigns authority to an agent acting on behalf of another, which keeps some responsibility for the outcome.
Each Part 11 audit entry captures user identity, date and time, action type and old versus new values, and approvals also record the reason. For model releases we would add the model version and the artefact digest, so the log names the exact object that moved. A Part 11 electronic signature must show the signer’s name, date and time, and its meaning (approved, reviewed, authored), and it must be bound to the record so that it cannot be copied or removed without detection. Every signing event requires fresh entry of user ID and password, so a session login is not enough and “click to approve” is non-compliant. The trail itself has to be tamper-evident: no user, administrators included, can modify or delete entries, and any attempted alteration is logged.
Do we need an approval gate before every batch run, or can we approve the model version and let runs proceed?
A gate per run belongs where an individual run’s action is irreversible, financially material, compliance-sensitive or judgement-heavy. JMG Group’s guidance on approval gates places them by consequence: the same action can be automatic in one context and gated in another, depending on what a wrong outcome would cost. Thresholds are the simplest way to express that rule, because they are unambiguous and auditable.
Version approval does not last forever. SR 11-7 expects a periodic review of each model at least annually, and material changes are subject to validation. Corporate.ai’s guide adds triggers for revalidation: a material model or prompt change, a new data source, a new user population or use case, a performance threshold breach or a significant incident. Regulated records can force the per-run answer: where GMP batch data must be reviewed before release, the batch’s audit trail must be reviewed before release too, so a quarterly schedule does not suffice. Even an unattended nightly run on an approved version should carry an automatic check that the version which ran is the version that was approved. Gates also work better routed to a role than to a person, so that one absence does not stall the process.
How do we template and validate field mappings per customer so each change is traceable?
Per-customer field mappings belong in versioned configuration templates kept apart from integration code, with every extracted field validated against the customer’s SAP schema before anything posts. TechnoLynx builds that templated mapping and shared schema-validation layer as a Production AI Monitoring Harness engagement, starting by cataloguing each customer’s SAP schema variations and the mapping patterns they share.
With templates, onboarding a new customer should mean writing a template rather than changing the pipeline, with each template change kept as a reviewed, versioned commit. Corporate.ai’s governance guide treats versioned prompts and configurations as part of normal change control, alongside a versioned regression test set run before material changes. Schema validation should check types, required fields and formats before posting, so errors are rejected at validation rather than surfacing as wrong postings downstream.
SAP’s reference architecture for Document AI shows how exception handling can stay generic: each extracted field carries a confidence score from 0 to 100%, documents with all fields above the configured threshold (typically 90% for critical fields) proceed automatically, and low-confidence documents wait for human validation in the Document AI workspace. Every human correction is itself an audit event worth keeping: who changed which field, from what value to what value, and why.
Two limits apply. Heavily customised SAP configurations should get template extensions, and each template should be pinned to the schema version it was validated against so drift shows when a customer changes its configuration. Treat this design as engineering judgement rather than an industry standard.
Turning scattered logs into one evidence pack you can regenerate
A defensible evidence pack consolidates logs and documents from every tool and vendor into one data model with provenance on each entry, generated by a repeatable pipeline rather than assembled by hand for each request. TechnoLynx can build that regenerable evidence pack, with provenance on each entry, as Production AI Reliability work, starting with an inventory of where each piece of evidence lives today and who owns it.
The W3C PROV data model defines provenance as information about the entities, activities and people involved in producing data, used to judge its quality, reliability or trustworthiness. Its agents carry responsibility for activities and entities, and attribution ascribes an entity to an agent, which is the “who did what” an auditor asks about. A PROV bundle is itself an entity, so the pack can record its own provenance: who assembled it, from which sources, and when. The 2020 multi-institution report Toward Trustworthy AI Development notes that AI development already produces a wide array of audit-trail material, such as code changes, training-run logs and model outputs. The same report identifies the lack of traceable logs across problem definition, design, development and operation as a cause of weak accountability for claims about AI systems.
When the original lineage is missing
Lineage inferred by correlating surviving artefacts (timestamps, inspection logs, PLC counters) is weaker evidence than lineage captured by design. PCAOB auditing standard AS 1105 states that evidence from a knowledgeable independent source is generally more reliable than evidence from internal sources only, that the reliability of internal records depends on the controls over their production, and that more evidence is needed as risk rises. In practice, correlating against known change events such as threshold updates or deployments bounds the uncertainty, but the pack should label the result as inferred and seek corroboration from a source outside the team that produced the logs. Our related work on building an audit-ready model documentation and approval package covers what that package should contain once the lineage is settled.
Deadlines, multiple vendors and what to document now
A tight submission window is survivable only when each section of the pack has a pre-agreed owner, so sign-offs run in parallel instead of queueing. A reconciled multi-vendor dossier is only as strong as its weakest contributor’s traceability, which makes a common evidence format worth negotiating with co-packers and suppliers before a dispute rather than during one. Whether simulation evidence can stand in for repeated live tests is the regulator’s decision, and where a regulator specifically requires live test data, no amount of simulation closes the gap. Over-documenting is not the answer to “what if they ask for more later”; capturing evidence in structured form at the source is, because a later request then becomes a query instead of a dig through raw logs.
Making the traceability check repeatable instead of a one-off reconstruction
A traceability check becomes repeatable when lineage, approvals and configuration are captured as structured records at the moment they happen, and a scheduled, documented review reads those records. TechnoLynx builds the approval evidence packs that check rests on as part of AI Governance and Trust, packs meant to survive an external auditor, a procurement committee or a regulator.
How do we make a traceability check reusable for the next audit?
Each registered model version in MLflow links back to the run, logged model or notebook that produced it, so the training data and parameters behind a deployed version can be traced without reconstruction. Corporate.ai’s guide adds versioned prompts and configurations and automated evidence collection to the same programme. The review is the other half. Klyverity’s guidance on Part 11 audit-trail review lists six elements a review SOP needs: scope, frequency, roles, what to look for, how to document and what happens when anomalies are found. Administrators fall inside the review scope, and a system that lets admin actions bypass the trail is itself a finding. Review frequency should match the review frequency of the data the trail covers rather than one calendar interval for every system.
Each completed review needs its own record: the date, the system and period reviewed, the reviewer’s name and signature, what was checked, whether anomalies were found and how they were dispositioned. The SOP and the review records are separate compliance assets, and an SOP with no execution records offers no protection during an inspection. SR 11-7 likewise expects internal audit to verify records of model use and validation, testing whether validations happen on time.
How should reviewer decisions and disagreements be logged so the audit trail holds up under review?
Every reviewer decision should be logged as a gate event with a named reviewer, the decision, a comment, a server-stamped timestamp and a snapshot of exactly what was under review. Digital Applied’s approval-gate framework specifies nine fields per gate event and notes that a missing field is what gets flagged in audits. Its key point is the state diff: without a snapshot of what the gate was reviewing, auditors cannot see what was approved, and including it turns the gate from a checkbox into a defensible artefact.
Fields to record for every approval gate event
| Field group | What to record |
|---|---|
| Location | Workflow ID, gate ID, event timestamp in UTC (ISO-8601), all stamped server-side rather than entered by the user |
| Decision | Reviewer ID of a named individual, decision (approve, reject, escalate or defer), free-text comment required on reject and escalate |
| Reviewed state | Structured snapshot of what was about to happen when the gate triggered |
| Performance | Time to decision, SLA tier, escalation chain showing which reviewers the event passed through |
| Context | The proposed action, its inputs, the rule that triggered the gate, any edits made and the final outcome |
| Model release | Model version, artefact digest and the registry tag or alias the decision set |
A disagreement between a QA reviewer and the original analyst should appear as two attributed judgements plus a resolution that names who resolved it and on what basis, never as a silently overwritten decision. SR 11-7 treats overrides the same way: cases where model output is ignored, altered or reversed should be documented, and their reasons and performance tracked. For monthly re-review of closed alerts, recording the sampling frame and the random seed lets anyone regenerate the same draw later. The right sample size depends on the statistical design your regulator expects, and that is a question for your model-risk or compliance function rather than a number to borrow from another audit regime.
Who can build our approval gates and evidence pack, and should we do it in-house?
TechnoLynx builds approval-grade evidence around model releases under its AI Governance and Trust practice: task-specific evaluations, governance evidence packs, an approval workflow and lineage for production decisions that an auditor or model-risk committee can read. On building in-house versus bringing in a specialist, a team already running a mature MLOps platform alongside an active compliance function can often extend what it has. Outside help earns its place when the gate, the identity plumbing and the evidence format all have to work together the first time an auditor asks. When choosing a partner, we would ask to see the evidence format before any build starts, and check that the partner states plainly which lineage is designed-in and which is inferred.
The engagement produces the artefacts an audit needs; it is not legal advice, regulatory sign-off, certification or a promise that a particular audit will pass. Interpreting what a specific regulator requires is work for your compliance owner or a regulatory consultant. Independent assurance of the result belongs to an internal or external auditor with no stake in it, since independence is what addresses concerns about self-reporting. A two-person team with modest stakes may need nothing more than the compensating-control pattern described in the small-team section.
Designed-in traceability costs less than any reconstruction
Across deploy permissions, gate records, field mappings and evidence packs, the pattern holds: evidence captured where the action happens is strong, and evidence rebuilt afterwards is weaker and costs more every time someone asks for it. The first question to settle is which of your release paths (the hotfix, the manual override, the template edit made on a Friday) does not yet leave a named, timestamped record. That path is the one to close first.
FAQ
What is an audit trail under 21 CFR Part 11?
Under Part 11, an audit trail is a secure, computer-generated, time-stamped record of the creation, modification and deletion of electronic records, kept as a permanent chronological log for traceability and accountability.
