trust

AI Policy

Last updated: October 19, 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 Workspace, 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 Workspace

The Workspace has one AI feature: an assistant that only TrazTech staff use. Clients never talk to a model in the Workspace. When a consultant working on your engagement asks it to, the assistant reads your workspace (answers, registers, evidence and documents you uploaded) and drafts or files work there: a questionnaire answer, a policy draft, a review of a supplier's report, a date on the calendar. The model is provided by Anthropic, under commercial terms that exclude training on our inputs. Anthropic is listed among our subprocessors.

How it is controlled:

• It never sends email. What it files shows up in your Workspace; anything that would email you, a supplier or anyone else is left for a person to send.
• Restricted where your agreement says so. If your agreement with us restricts AI, it is switched off for your workspace entirely: no panel, no drafting, nothing sent to the model.
• A person confirms every change. The assistant does not act on its own. Each change it proposes is shown to the consultant, who confirms it, and it is logged in your activity feed as made through the assistant.
• Drafts stay drafts. Anything it writes from reading a document, and anything you or a buyer will read, stays a draft until a person has reviewed and accepted it.
• Identifiers are removed before anything is sent. Government ID, health card, medical record, payment card and bank numbers, and labelled dates of birth, are detected by pattern and replaced with a marker in everything that goes to the model. Names and work email stay, because the work needs them.
• Some acts are never the assistant's. It cannot sign or approve anything, issue a report or letter, grant auditor access, change billing or commercial terms, or read stored credentials.
• Only staff who may make changes can use it. Read-only staff accounts cannot run it.

Several other 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.

Reading dates and terms out of an uploaded data processing agreement is pattern matching on our own server. For a supplier's assurance report, our staff can also have the model read it and draft the dates, auditor, conclusion and exceptions, which a person checks before anything is recorded. If we add an AI feature that clients use directly, 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:

• The Workspace assistant reads content supplied by others (a vendor's report, an uploaded document) only when a consultant asks it to, and what it reads is treated as material to analyse, never as instructions.
• It cannot act on its own: every change is confirmed by a consultant, and the acts that matter most (signing, approving, issuing, granting access, billing) are not available to it at all.
• 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 or to any client environment. Inside the Workspace a successful injection could at most propose a change, which a consultant sees before it is made.
• 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. In the Workspace this is also automatic: identifiers are stripped from what is sent to the model, and personal data a connected system returns that no check needs is removed before it is stored.
• 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, and a person confirming every change.

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 a deployer, not a provider. We do not develop or place an AI model on the market. We use general-purpose AI models supplied by third parties.
• Our uses are minimal-risk: drafting, research, code assistance, and the staff assistant in the Workspace, which drafts and organises compliance records under a consultant's direction. The Act imposes no specific obligations on these 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 client or anyone else in a way that could be mistaken for a human: the Workspace assistant is used by our staff only, and what it does in your workspace is logged as done through the assistant. 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 traztech Workspace.

Common questions