Compliance as a Service · the agents
AI agents that draft, map and check. People still decide.
Nank.ai runs a set of agents inside the compliance platform. They write policies from your own context, map them to controls, review them as your business changes, and check that controls run. Here is what each one does, and where a human takes over.
- Organisational context
- Policy drafting
- Control mapping
- Policy review
- Implementation checks
- Operation checks
5
Jobs the agents carry
12
Frameworks they map controls against
0
Policies shipped from a template pack
Canada
Data held in your own country
The argument
Why agents, and not a template pack
Most compliance tools hand you a policy library. You fill in the company name, change a few words and file it. That works until an auditor asks a follow-up question, at which point the gap between the document and the business becomes the finding.
An agent starts from the other end. It reads what your organisation is, then writes the policy that fits. The draft still goes to a person. That part matters more than the drafting, and it is why the compliance manager and the agents ship together.
Capabilities
What the agents do
Five jobs. Each one produces something your compliance manager reviews before it counts. Buyers ask for SOC2 or SOC 2 and for ISO 27001, and the same agents serve both.
Identify organisational context
Your sector, size, systems, data types, customers and the laws that reach you. This is the ISO 27001 Clause 4.1 and 4.2 work, and everything downstream depends on it.
Create policies
Policies drafted from that context rather than from a shelf. A firm holding Ontario health data gets different wording from a fintech selling into the United States.
Map policies to controls
Every clause tied to the controls it supports, and every control tied to the framework requirements it answers. Write once, satisfy each framework that asks.
Review policies
Policies drift. The agents re-read them when your systems, headcount, products or frameworks change, and flag the clauses that no longer describe the business.
Verify implementation
Does the control exist as designed? The agents check configuration in your cloud, identity, code and device tooling against what the control says.
Verify operation
Did the control run, on schedule, with a record? A control that exists but did not operate is the exception an auditor writes up in a SOC 2 Type 2 report.
Where it starts
Organisational context is where the work starts
ISO 27001 opens with two clauses most projects rush. Clause 4.1 asks you to determine the internal and external issues relevant to your management system. Clause 4.2 asks who your interested parties are and what they need. Get those wrong and every later control decision inherits the error.
The context agent gathers the inputs a person would ask for. What you sell and to whom. Which systems hold customer data. Where that data sits. Which regulators and contracts reach you. Whether you handle health records, card data or personal data from Europe. How your teams sit, and who approves what.
That profile drives the rest. It shapes which Annex A controls are candidates for exclusion. It shapes which policies you need at all. It shapes which framework mix your buyers will ask for. Your compliance manager reviews that profile with you first. The complete ISO 27001 guide in our library sets out where context sits in the wider sequence.
Verification
Two kinds of verification, and the difference matters
Auditors separate design from operation, and so do we.
Implementation
Asks whether the control exists as designed. Multi-factor sign-in enforced on the identity provider. Branch protection on the repository. Disk encryption on the fleet. The agents read the configuration through integrations and compare it to the control text.
Operation
Asks whether the control ran over time. The access review happened in each quarter and someone signed it. Every production change carried an approval. Onboarding training completed within the window. This is what a SOC 2 Type 2 examination tests, and it is where programs that look green on a dashboard come apart.
Where automation stops
Integrations reach your technical controls. They do not reach a board minute, a vendor review meeting, a door log at a leased office, or a call with a sub-processor. Those controls still need a person to produce the record. Any provider claiming near-total automation is counting only the easy controls. Your compliance manager tells each owner what to produce and when, and keeps that list as short as the frameworks allow.
Division of labour
Who decides what
The division of labour is the honest part of this page. Three parties, three jobs.
1
The agents draft and check
Context profiling, policy drafting, control mapping, policy review, configuration and operation checks. Volume work, done the same way every time, at a pace no team matches by hand.
2
Your compliance manager rules
Applicability, risk treatment, scope boundaries, exceptions and compensating controls. Your manager reviews every agent output before it becomes your policy or your evidence.
3
You approve and operate
Leadership approves policies and accepts risk. Control owners perform the controls and supply the records no integration can reach.
Limits
What we do not let an agent decide
Three decisions stay with people, because an auditor will hold a person accountable for them.
1
Risk acceptance
Deciding a risk is tolerable is a business judgment with consequences. Leadership owns it, and ISO 27001 expects a named risk owner rather than a system.
2
Applicability
Ruling that an Annex A control does not apply is the call your certification body tests hardest. So is writing the reason into the Statement of Applicability. Your compliance manager makes both.
3
Approval
A policy needs an approver with authority. “Generated by our platform” is not an approval, and an auditor asking who reviewed a policy will not accept it as one.
Our own governance
Governing the AI, because we use it
A compliance firm running AI agents on client data should hold itself to the standard it sells. ISO 42001 is the first certifiable AI management system standard. It asks for what you would want from any vendor using AI in a regulated workflow. Defined roles. Impact assessment. Human oversight of machine output. A record of what the system did and why.
So ask three questions of any compliance vendor using AI. How do they govern their own AI. Where does your data go when an agent processes it. Does your content train anyone’s model. Those questions are becoming standard in Canadian security reviews, and our AI risk assessment guide covers how to put them to a supplier.
Canadian coverage
SOC 2 and ISO 27001 across Toronto, Ontario and Canada
Nank.ai works from Toronto. The agents run inside the compliance platform, and client data stays in the client’s own country.
That last point does real work in Canada. A Canadian CPA firm can issue your SOC 2 report and it carries the same weight with United States buyers. For ISO 27001, the Standards Council of Canada accredits the certification bodies here. And Canadian privacy law is not one law. The context agent maps PIPEDA, PHIPA, Quebec Law 25 and the PIPA statutes against what your business does. Not against all of them at once.
Canadian data residency compliance
The part most vendors leave out
Neither SOC 2 nor ISO 27001 contains a data residency requirement. Nothing in the Trust Services Criteria asks where your data sits, and ISO 27001 sets no rule either. So a clean report or a valid certificate will not answer the residency question a Canadian health, finance or government buyer asks. It is a separate commitment. Nank.ai holds client data in the client’s own country, and that includes anything the agents process.
Questions
Frequently asked questions
They draft them from your organisational context rather than from a template pack, which is a real difference in the wording an auditor reads. Every draft goes to your compliance manager for review, and then to an approver in your business. Nothing becomes your policy because a model produced it.
From what you tell us at scoping, from the systems you connect, and from the documents you already hold. The agent assembles a profile covering sector, size, data types, systems, customers and the laws that reach you. That is the ISO 27001 Clause 4.1 and 4.2 work. Your compliance manager reviews the profile with you before anything sits on top of it.
We do not publish a percentage. The honest answer depends on your control set. Technical controls in connected systems are well covered. Controls that live in human processes, physical spaces or third-party relationships are not. Treat any vendor quoting a single automation figure with care, and ask which controls it excludes.
Auditors accept evidence, and they test where it came from. A configuration snapshot pulled from your identity provider is evidence regardless of what collected it. What they will not accept is a document with no human approver, or a control status nobody verified. That is why every agent output passes through your compliance manager.
Ask us this on the scoping call and get the answer in writing, from us and from every vendor you are comparing. It belongs in your contract rather than on a marketing page. The related commitment we do publish is residency: client data stays in the client’s own country.
Yes, and the reverse is the better way to see it. The agents exist so one experienced compliance manager can run a program that used to need a full-time hire. Applicability rulings, risk treatment, scope boundaries and the auditor relationship all need a person who has done it before.
More in the SOC 2 guide, the compliance library and on the Nank.ai blog. See also compliance solutions by size, industry and framework.
See what the agents produce for your business
Book a scoping call. We will build the context profile and show you what the agents draft from it. We will also tell you which controls still need a human record.