Approvals, Audit & Lineage — Responsible AI Governance at Scale

Governance becomes real when it leaves the policy document and shows up in the work. Approvals decide whether a change is allowed to proceed. Audit records show what actually happened. Lineage explains where data, models, prompts, and outputs came from. Together, they turn trust from a feeling into something you can inspect.

Start with the three questions

Every controlled system has to answer three simple questions. Who said this was allowed? What actually happened? Where did the result come from? Approvals answer the first question, audit answers the second, and lineage answers the third.

These ideas are older than modern software. A bank loan needs a sign-off, a transaction record, and a file showing the evidence used to make the decision. Artificial intelligence, or AI, and data systems need the same pattern, but the moving parts are less visible. Data can be copied, prompts can change, models can be updated, and automated agents can act faster than a human reviewer can follow.

The goal is not to slow every change. The goal is to make important changes visible, reviewable, and repeatable. A lightweight approval may be enough for a low-risk dashboard. A customer-facing AI feature that influences eligibility, pricing, safety, or legal rights deserves a stronger record.

Approvals record who allowed it, audit records what happened, and lineage records where it came from.

Approvals decide before action

An approval is a recorded decision that a proposed action may go ahead. It should say what is being approved, who approved it, what evidence they saw, what conditions apply, and how long the approval remains valid.

Good approval design is risk-based. If every tiny edit needs a committee, people will route around the process. If nothing needs approval, serious changes will reach production without informed consent. The useful question is: what could go wrong if this change is wrong?

In AI and data work, approval points often appear before a model is deployed, before a data source is connected, before sensitive data is used, before an automated action is enabled, or before a prompt template is changed for a regulated workflow.

⚠️

Approval is not a rubber stamp. If the approver cannot see the relevant evidence or has no authority to say no, the approval record has little value.

Audit records after action

An audit trail is a durable record of events. It does not merely say that the system exists; it records activity inside the system. A useful audit event can be read months later by someone who was not present and still tell a coherent story.

The minimum audit question is: who did what, to which object, from where, when, and with what result? In software, the who may be a person, a service account, an application programming interface, or API, key, or an automated agent. That identity should come from a trusted identity provider, such as Microsoft Entra ID, rather than from a free-text name.

Audit logs are evidence, not decoration. They should be protected from casual editing, retained for a defined period, searchable by authorized people, and connected to incident response. If a log can be silently changed by the same person whose actions it records, it is not strong evidence.

Actor: the person, service, or agent that performed the action.
Action: the operation performed, such as approve, deploy, delete, export, or override.
Object: the dataset, model, prompt, workflow, record, or configuration that changed.
Time: a reliable timestamp with time zone and clock source understood.
Outcome: success, failure, partial completion, or denial, including the reason when known.
Context: source location, request identifier, policy version, and related approval when relevant.

A strong audit event records who acted, what action they took, on which object, and the result.

Lineage explains where results came from

Lineage is the record of origin and transformation. It shows how a result was produced from earlier inputs. In a data pipeline, lineage may show that a report column came from three source tables and two transformations. In an AI system, lineage may include the model version, prompt template, retrieval index, source documents, tool calls, and safety filters used to produce an answer.

Lineage matters because outputs are rarely self-explaining. A number in a dashboard, a recommendation from a model, or an answer from a generative AI system can look authoritative even when it was built from stale, incomplete, or unauthorized inputs. Lineage lets you trace the path backward.

Lineage does not require recording every byte forever. It requires recording the parts needed to understand, reproduce, challenge, or retire a result. The right level of detail depends on risk, regulation, and operational cost.

Lineage records how sources and transforms produced a result, so you can trace the path backward.

The three records strengthen each other

Approvals, audit, and lineage are strongest when they reference one another. An approval should point to the exact change it allowed. The audit trail should show that the approved change was the one actually deployed. The lineage record should show which later outputs depended on that change.

This connection is what makes investigation possible. Suppose a model starts giving poor answers after a release. Approval records show why the release was allowed. Audit records show who deployed it and whether anything else changed. Lineage records show which outputs, customers, reports, or downstream systems were affected.

The same pattern applies in platforms such as Microsoft Foundry, data warehouses, automation systems, and custom applications. The product names change, but the control logic stays the same: bind decisions to actions, and bind actions to consequences.

The real decisions leaders and practitioners face

The hard part is not agreeing that governance matters. The hard part is choosing where to spend attention. Every approval, log, and lineage capture has a cost. Too little control creates risk. Too much control creates delay, resentment, and shadow systems.

Leaders decide the risk appetite: which changes require human approval, which can be automated, which data needs strict lineage, and how long evidence must be retained. Practitioners turn those choices into concrete workflow rules, access controls, log schemas, dashboards, and release gates.

A healthy design starts with the decisions that would be painful to explain after an incident. If the organization would need to know who approved a customer-impacting model, what data it used, and which customers were affected, then those records should be captured before the incident happens.

Which actions are low enough risk to approve automatically?
Which actions require separation of duties, where the requester and approver cannot be the same person?
Which outputs must be reproducible, and for how long?
Which logs contain sensitive data and need extra protection?
Which lineage records are needed for legal, safety, financial, or customer support reasons?
Who is allowed to break glass in an emergency, and how is that exception reviewed afterward?

📌

Govern the painful questions. Start by capturing the evidence you would most need if a regulator, customer, executive, or incident team asked what happened.

Leaders set the risk appetite; practitioners turn those choices into concrete workflow rules.

Build habits, not paperwork

The best governance records are created as a by-product of normal work. A pull request, release pipeline, data catalog update, or model deployment can capture evidence automatically. Continuous integration and continuous delivery, or CI/CD, systems can enforce tests and approval gates before changes move forward.

Do not ask people to type the same facts into three forms. Reuse identifiers. Connect the approval ticket, deployment event, model version, dataset version, prompt version, and incident record. A shared identifier is often the difference between a quick investigation and a week of manual reconstruction.

Finally, review the records you collect. If no one ever reads an approval, searches an audit trail, or follows a lineage graph, quality will decay. Periodic sampling, incident retrospectives, and access reviews keep the system honest.

✅

Automation helps. Controls work best when the default path is also the governed path.

Key takeaways

Approvals answer who allowed a change before it happened.
Audit trails answer what actually happened after action was taken.
Lineage answers where an output came from and what it depended on.
The three records are most valuable when they reference the same change, version, or request identifier.
Risk should determine the depth of approval, logging, and lineage, not habit or fear.
Good governance is built into normal workflows rather than added as manual paperwork afterward.

Glossary

Approval: A recorded decision that a proposed action is allowed to proceed under stated conditions.
Audit trail: A durable record of events that shows who did what, when, to which object, and with what result.
Lineage: A record that shows the origin, transformation, and dependencies behind a data item, model output, report, or AI answer.
Artificial intelligence: Software techniques that perform tasks usually associated with human judgment, such as classification, prediction, generation, or planning.
Application programming interface: A defined way for software systems to request actions or exchange data with each other.
Separation of duties: A control that prevents one person from both requesting and approving a sensitive action.
CI/CD: Continuous integration and continuous delivery, a practice of automatically testing and releasing software changes through controlled pipelines.
Identity provider: A system that verifies users, services, and applications so their actions can be tied to trusted identities.