# AI governance and audit readiness: an engineering playbook

> A proposed engineering approach to AI inventories, human review, execution records, and staged legacy changes, with regulatory scope checked separately.

**Author:** André Queiroz (dezotech) · **Published:** 2026-05-29
**Source:** https://dezotech.com/en/insights/adopt-ai-without-failing-your-next-audit

---

I spent 16 years operating banking and government systems in Brazil.
That operational experience informs my attention to approvals, exceptions,
and continuity; it was not a role building those systems.
Today I develop shadow-scan and have led the development of a real-time AI platform.

The approach below is proposed engineering guidance for teams introducing AI
into an existing workflow. It is not a report of DezoTech client engagements
or a guarantee of an audit result. The starting point is a concrete question:
**who approved this use, and what record supports that decision?**

## Start with the workflow and its owners

An AI tool can enter a process through an approved integration or through an
individual's everyday work. An inventory should capture both known tools and
uses that need investigation, with the data involved and the people responsible.

For example, a document summary may pass from an operations employee to a
reviewer and then into a system of record. Map that whole path: who can submit
data, who checks the output, what happens when the output is wrong, and where
the final decision is recorded. This is an illustrative scenario, not a client
result.

Network logs can help identify traffic to AI services. They do not establish
what a prompt contained or prove that all AI use has been discovered. Combine
technical signals with authorized access to documentation and conversations
with process owners. For a related approach, see the
[shadow-AI containment plan](/en/insights/shadow-ai-90-day-containment-plan).

## A seven-point engineering checklist

Use these checks to agree scope and acceptance criteria with operations, IT,
security, and the people accountable for the process. The controls and evidence
needed depend on the use case, data, and applicable requirements.

<Checklist heading="Review before deployment" items={[
  'Inventory AI uses and data flows, recording source coverage and known gaps.',
  'Assign a named owner for each use case and a responsible reviewer for exceptions.',
  'Identify applicable requirements separately from voluntary risk-management frameworks.',
  'Define the execution records needed: system and model versions, relevant inputs or references, output, and approvals, with appropriate access and retention controls.',
  'Set human review and escalation points according to the consequences of the decision.',
  'Test recovery and rollback options, including data changes, dependencies, and acceptable interruption.',
  'Agree acceptance tests, monitoring, and a process for reviewing changes after deployment.'
]} />

Records should let a reviewer understand how a particular decision was reached.
They also need proportionate privacy and security controls: capturing every raw
input indefinitely can create a separate exposure. Define what to preserve,
who may access it, and how long it is needed.

Integrity checks answer a narrower question than authenticity. A hash comparison
can reveal a mismatch against a preserved reference, but a hash alone does not
prove who created the record or when. The
[capture, seal, replay playbook](/en/insights/ai-audit-trail-capture-seal-replay)
explores execution records in more detail. Review its recommendations against
your own system and requirements.

<InlineCTA href="/en/contact" cta="Discuss your workflow" heading="Start with an AI and workflow assessment">
Describe one workflow, its systems, and the decisions that need review. We can
discuss an assessment covering the process map, risks, priorities, and a staged
implementation plan. Scope, timing, and pricing are defined by proposal.
</InlineCTA>

## Modernize one decision path at a time

A staged migration can make a change easier to inspect and test. It is an
option to evaluate against the architecture and continuity requirements,
not a universal answer for every legacy system.

One possible approach is the strangler-fig pattern: place an interface in front
of an existing capability and move selected paths to a new component over time.
Define the boundary before implementation. Which data does the new component
read or change? Which integrations depend on its behaviour? Which exceptions
still need the old path?

- **Transform** — build a bounded component alongside the existing capability
  and test it with representative data.
- **Coexist** — compare outputs and reconcile state where appropriate. Test
  recovery paths and establish when a transition must stop.
- **Eliminate** — retire the old capability only after agreed acceptance,
  operational ownership, and continuity checks are complete.

Keeping the old service available does not make rollback automatic. Database
changes, writes to other systems, and external dependencies can prevent a clean
reversal. Test the recovery procedure, document its limits, and agree any
required interruption before changing production traffic.

Not every slice needs AI. Conventional rules, integration work, or a smaller
software change may solve the problem with fewer operating constraints.
Where AI assists development, review generated code, permissions, data access,
and tests before accepting the change. Local models are one possible deployment
choice; they do not remove the need for those controls.

<Callout heading="Context → Constraint → Approach → Acceptance">
Record the workflow and its owners; what must keep working; the proposed change
and recovery options; and the evidence the team will use to accept the result.
This provides a practical structure for discussing scope before implementation.
</Callout>

## Check regulatory scope before choosing obligations

Engineering controls can support a review, but they do not establish legal
compliance on their own. Identify the organization, jurisdiction, system role,
and use case with the people responsible for legal and compliance decisions.

- **Canada:** the federal Directive on Automated Decision-Making has defined
  institutional and system scope. It does not apply to every Canadian
  organization, supplier, or AI tool. Use the Government of Canada's
  [scope guide](https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/responsible-use-ai/automated-decision-making/guide-scope-directive-automated-decision-making.html)
  to assess whether the particular department and decision system fall within it.
- **NIST:** the [AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
  is intended for voluntary use. It can help structure risk-management work;
  adopting it is not, by itself, a certification or evidence that all legal
  requirements have been met.
- **European Union:** the [European Commission's AI Act overview](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)
  describes risk-based rules for particular uses and roles. Check territorial
  scope, the system's use, and the organization's responsibilities before
  selecting requirements or relying on an implementation date.

These references support a scope discussion. They are not a universal deadline
map or legal advice for a particular deployment.

## FAQ

<FAQ items={[
  {
    q: 'Can AI be introduced without rewriting the entire legacy system?',
    a: 'Sometimes. A bounded integration or staged migration may be feasible if the existing interfaces, data, and continuity requirements support it. Test dependencies and recovery options before choosing the approach.'
  },
  {
    q: 'What should an AI and workflow assessment produce?',
    a: 'An agreed process map, identified owners and risks, prioritized changes, and a proposed implementation plan with acceptance criteria. The precise artifacts and access needed are defined in the scope.'
  },
  {
    q: 'Do execution records guarantee an audit pass?',
    a: 'No. Records help reviewers inspect a workflow, but an audit depends on the applicable requirements, control design, operation, and evidence. Integrity checks alone do not establish compliance or guarantee an outcome.'
  }
]} />

Choose one workflow and trace a representative decision from input to review
and final record. The gaps in that trace provide a concrete starting point for
an assessment and a staged engineering plan.

For a delivery context, explore our [AI governance service scope](/en/governance)
and [supervised document automation](/en/automation), including deliverables,
review criteria and dependencies.