AI governance and audit readiness: an engineering playbook

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.

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.

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 explores execution records in more detail. Review its recommendations against your own system and requirements.

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.

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 to assess whether the particular department and decision system fall within it.
• NIST: the 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 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

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 and supervised document automation, including deliverables, review criteria and dependencies.