// trust

AI Policy

Last updated: July 31, 2026

1. Why this page exists

Most AI policies are written to reassure rather than to inform. They use the word "responsible" a great deal and never tell you what actually runs, on what data, with what oversight. That is not useful to a buyer doing vendor due diligence, and it would be embarrassing coming from a firm that reviews AI governance for clients.

So this page is specific. It says where AI is used, where it is deliberately not used, what happens to your data, and what we do not have. Where a capability does not exist yet, we say so plainly rather than leaving it ambiguous.

2. Our principles

• A human is accountable for every output. AI does not sign anything. A named person does, and that person is answerable for it.
• Your data is not a training corpus. Not ours to give, and not a trade we would make.
• Use it where it is good, avoid it where it is not. AI is genuinely useful for drafting, summarising, and reading code. It is not reliable at judging whether a control is adequate, and we do not ask it to.
• Disclosure over cleverness. If AI materially shaped something you receive, you can ask and we will tell you.
• Proportional controls. We apply the same tiering to our own AI use that we would apply to a client's: higher scrutiny where output affects a decision, minimal ceremony where it does not.
• The policy tracks reality. This page is updated when practice changes, not once a year as an exercise.

3. Where AI is used in delivery work

AI assistants, which are commercial large language models accessed through business accounts, are used by our team for:

• Drafting. First drafts of policy language, report sections, and client-facing explanations, which a consultant then rewrites and verifies.
• Research and summarising. Reading long standards, regulations, and vendor documentation, and pulling out the parts that need a human to read carefully. The underlying source is always checked before a conclusion is drawn from it.
• Code and configuration review. Reading source, infrastructure code, and configuration for likely weaknesses, as a first pass that a security engineer then confirms by hand.
• Engineering our own software. Writing and reviewing the code behind traztech.ca and the compliance platform, with human review before anything is deployed.
• Internal writing. Marketing copy, blog drafts, and internal documentation, edited by a person before publication.

4. Where AI is not used

• It does not decide whether a control is met. That judgement is made by a consultant looking at the actual evidence.
• It does not set risk ratings, severity, or CVSS scores. Those come from a human assessing exploitability and impact in your environment.
• It does not run exploits or make changes in a client environment. Testing is performed by people, under an agreed scope and rules of engagement.
• It does not produce audit conclusions. We do not issue audit opinions at all, with or without AI. See the Terms of Service.
• It does not make decisions about individuals. No AI is used in hiring, performance assessment, credit, or anything else with a legal or similarly significant effect on a person.
• It does not talk to you unsupervised. There is no autonomous AI agent emailing clients, answering support, or acting on a client system on our behalf.

5. Training: the direct answer

6. Human review before anything reaches you

Every client-facing artefact goes through a person before delivery. In practice that means:

• A named consultant owns each deliverable and is accountable for its accuracy, whether or not AI helped draft it.
• Factual claims about your environment are traced back to observed evidence, not to model output.
• Citations to standards, control identifiers, and regulatory text are checked against the primary source, because models get clause numbers wrong with great confidence.
• Findings, ratings, and recommendations are written or confirmed by the person who did the work.
• Code produced with AI assistance is reviewed before it is merged and deployed.

The rule is simple: AI can help produce a draft, but a human is always the last set of eyes and the accountable author.

7. AI in the compliance platform

The free compliance platform contains no AI features today. No model reads your workspace. No model reads your evidence. Nothing you type is sent to an AI provider.

A few things in the platform look like AI and are not, and it is worth being clear about which is which:

• Readiness scoring is arithmetic over your own answers. Met, partially met, not met, not applicable. Same inputs, same score, every time.
• Control scoping uses declared rules against your scoping answers, so a framework's full library is trimmed to what applies to you. The rules are fixed and inspectable.
• Gap ranking and effort estimates come from a fixed table of weights per control, not from a model's guess.
• Service recommendations and indicative quotes are rule-based, triggered only by controls you marked as not met or partially met, priced from published rates. They are deterministic, which is exactly why we can tell you why a recommendation appeared.
• Plain-English control guidance is a written library. It was authored and edited by our team, not generated on the fly when you open a control.

We are aware this is a place where a lot of products would claim AI. Deterministic logic is the honest description and, for compliance scoring, it is also the better engineering choice: an auditor can be shown exactly how a number was produced.

If we add an AI feature, for example evidence summarisation or a drafting assistant for policies, it will be opt-in, it will be labelled in the interface, this page will be updated before launch, and the no-training commitment in section 5 will still apply.

8. Vendor and model-provider due diligence

We hold AI vendors to the same process we run for clients on third-party risk. Before a tool is approved for work use, we look at:

• Whether inputs are used for training by default, and whether that can be turned off contractually rather than by a settings toggle alone.
• Data retention: how long prompts and outputs are kept, and whether zero or short retention is available.
• Where processing happens, and what cross-border transfer terms apply.
• Sub-processors, and whether the vendor discloses them.
• Security posture, including current SOC 2 or ISO 27001 status and published incident history.
• Whether a data processing agreement is available and whether it is one we would sign.
• Access controls: business or enterprise tenancy, single sign-on, and administrative visibility. Personal accounts are not used for client work.
• Whether the tool trains on our code or documents as a side effect of ordinary use, which rules out several otherwise good products.

Approved AI tools are recorded on our internal register with the owner, the purpose, the data classes allowed, and a review date. Anything unapproved is shadow AI, and we treat it the same way we would in a client environment: find it, assess it, approve it or remove it.

9. Prompt injection and data leakage in our own tooling

We test other people's AI systems for these problems, which makes it hard to be careless about our own. Two risks matter most.

Prompt injection

When an AI assistant reads text supplied by someone else, that text can try to issue instructions. In our work that could be a vendor questionnaire response, an evidence document, a log file, or a page fetched during research. Our controls:

• No AI assistant is wired into the compliance platform's data, so untrusted customer and vendor content never reaches a model automatically. This is the strongest control we have and it comes for free from section 7.
• Untrusted content that a consultant does paste into an assistant is handled as data to be analysed, never as instructions to be followed.
• AI assistants have no standing credentials to production systems, no ability to send email as us, and no authority to change a client record. A successful injection can produce misleading text; it cannot take an action.
• Every output derived from external content is reviewed by a person before it is used, which is where an injected instruction would surface.

Data leakage

• Client data is minimised before it goes anywhere near an assistant. We redact identifiers, use extracts rather than full exports, and prefer describing a problem over pasting a raw dataset.
• Secrets, credentials, API keys, and personal information are not pasted into AI tools. If a credential ever is, it is treated as compromised and rotated.
• Where a client contract restricts the use of AI tooling on their data, that restriction wins and we work without them.
• Business tenancies are configured for no training on inputs and the shortest retention the vendor offers.
• Staff are briefed on these rules, and they are conditions of working here rather than suggestions.

We do not claim these controls are complete. Prompt injection is an unsolved problem in the general case, and any firm that tells you it has solved it is worth a second look. Our position is to keep the blast radius small: no autonomous actions, no standing access, no untrusted content reaching a model unsupervised.

10. Where we sit under ISO 42001 and the EU AI Act

ISO/IEC 42001

ISO 42001 is the management system standard for AI. We use it as the structure for our own AI governance: a defined scope of AI use, an accountable owner, an AI risk assessment, an approved-tool register, supplier controls, and a review cycle. This page is the public part of that.

To be precise about status: we are not certified to ISO 42001. We align our practice to it and we help clients prepare for it, and those are different things from holding a certificate. If that changes, we will say so here with the certificate details and the certification body, and not before.

EU AI Act

• We are not a provider of an AI system. We do not develop or place an AI system on the market. The compliance platform contains no AI system, so no risk tier applies to it.
• Internally we are a deployer of general-purpose AI models supplied by third parties, for drafting, research, and code assistance. Those uses fall in the minimal-risk tier, where the Act imposes no specific obligations beyond general law.
• We deploy nothing in the Annex III high-risk categories. No AI in employment or worker management, education access, creditworthiness, essential services, biometrics, emotion recognition, law enforcement, migration, or justice.
• We use no prohibited practices under Article 5: no social scoring, no biometric categorisation, no emotion inference in work or education settings, no untargeted facial image scraping, no manipulative or exploitative techniques.
• Transparency. No AI system of ours interacts with a person in a way that could be mistaken for a human, and we do not publish synthetic media. Where AI materially shaped published content, we will say so on request.
• If we ship an AI feature, we will classify it before launch, document the classification, apply the transparency obligations that attach to it, and update this page.

We also track the NIST AI Risk Management Framework and Canada's federal AI directives, because clients ask about them and because they inform the assessment work we do for others.

11. If you use AI, and we are assessing you

When we assess an AI system for a client, we work under an agreed scope and rules of engagement, we do not use their models or data to improve anything of ours, and findings belong to the client. Red-team prompts, jailbreaks, and outputs generated during testing are handled as client-confidential material and are deleted on the schedule in the engagement agreement.

12. Questions, concerns, and disagreements

You can ask us anything on this page and expect a straight answer. Things people ask, and are welcome to ask:

• Whether AI was used on a specific deliverable, and how.
• Which AI vendors we use and under what terms.
• For a contractual commitment restricting or prohibiting AI tooling on your data. We will agree to it where we can deliver under it, and we will tell you if we cannot.
• To be told before we introduce an AI feature that would touch your workspace.

If you think we have used AI in a way that is inconsistent with this page, tell us. We will investigate, tell you what we find, and correct anything that was wrong. That is the same standard we hold vendors to when we assess them, and we would rather hear it from you than have you quietly conclude we are like everyone else.

13. Contact

Questions about this policy, or about AI in a specific engagement, go to [email protected]. Privacy questions about AI processing go to [email protected]. Security concerns, including anything you believe is a prompt injection or data leakage issue in our tooling, go to [email protected].

By post:

TrazTech Inc.
145 1/2 Church Street, Unit 5, Office 876
Toronto, Ontario, M5B 1Y4
Canada

Related reading: the Privacy Policy, the Terms of Service, and the free compliance platform.

Common questions