AI governance: policies, controls and evidence for responsible AI

SEYA Group helps enterprises write the policies, controls, and evidence for AI systems they already run or are about to launch. The work is mapped to the NIST AI Risk Management Framework and, where you want a management system, to ISO/IEC 42001. SEYA does not certify the programme and does not claim that a policy document makes a model safe. Engagements are led from our Vancouver office by senior engineers who also do the technical review.

Who this is for

Risk, security, and technology leaders who have been asked for an AI policy and do not want a binder that engineering will not follow. Teams that need to tell a board, a customer, or a regulator what decision the system supports, what data it uses, and who can turn it off. Companies that already have an AI security review underway and need the governance artefacts to match the technical controls.

What you get

• A system inventory. The AI systems in scope: purpose, users, data sources, model or API provider, and the business owner. A system with no owner is listed as a gap, not given one on paper.
• Policies that name a control. Acceptable use, human review, data handling, and vendor review, each pointing at a control someone can operate. The structure follows the NIST AI Risk Management Framework (govern, map, measure, manage). Where you are aligning a management system to ISO/IEC 42001, we map the same controls to that standard's clauses. Mapping is not a certificate. ISO certification, if you seek it, comes from an accredited body.
• Evidence. The records that show the policy was used: an approval, a test report from an LLM security assessment, a log of who changed a tool allow-list. We do not invent minutes for meetings that did not happen.
• A Canadian context note. The note records how the system sits under Canada's federal private-sector privacy law (PIPEDA) and whether any AI-specific statute is actually in force for that system. Proposed legislation, including the Artificial Intelligence and Data Act that was introduced with Bill C-27, is labelled as proposed. We do not treat a bill as a current legal duty. This note is engineering context for your counsel, not a legal opinion.

How an engagement runs

• Name the systems. One product or a short list. A programme that tries to govern every experiment on day one does not finish.
• Write the decisions. What the system may do, what it must not do, and who accepts residual risk. Technical limits found in security testing are written into the control, not parked in an appendix.
• Attach evidence. Each control names the system that produces the record. Pipeline checks from DevSecOps are used where they already exist.
• Hand it to the owner. The policy set and the evidence index belong to your company. SEYA does not remain the approver.

What you need in place

A business owner for each system in scope, counsel if you need a legal conclusion, and access to the architecture. If nobody has tested the prompts and tools yet, do that assessment before the policy claims a control you have not seen work.

Out of scope: a legal opinion, an ISO/IEC 42001 certificate, a statement that a model is unbiased or safe, and building the AI product. Published client work we can point to is still the security review pattern on the Boeing GoldCare Azure migration, where the client's InfoSec team vetted the infrastructure before go-live. That was not an AI governance programme. It is the review habit this service is built on.

Questions buyers ask

Are you certifying us to ISO/IEC 42001 or NIST?

No. NIST AI RMF is a framework, not a certification scheme. ISO/IEC 42001 is a standard an accredited body can certify against. SEYA maps your controls to those documents and writes down the gaps. We do not issue the certificate.

Does this replace a privacy review?

No. We will say which data the system can reach and where a privacy question needs your counsel. PIPEDA obligations are yours. The governance pack gives counsel something concrete to read. It is not a privacy legal memo.

Can the policy be shorter than the framework?

Yes. The pack covers the systems in scope, not every function in the framework. A control that does not apply is marked not applicable with a reason, instead of being copied in as empty text.

Book a cloud security assessment if a board or a customer has asked for an AI policy and you want it tied to the systems you actually run.