01
Acceptable use.
What the tools may be used for, what must never be pasted into a prompt, and what someone should do when they are unsure. The version that works is short and written for the person at 4pm on a Friday.
Writing the rules is the easy half. The half that decides whether they mean anything is where they are enforced.
The {configuration} is the policy.
Most AI policies are a document nobody can enforce. Somebody writes acceptable-use rules, they are circulated, and the system they govern has no idea they exist. We do the advisory work and then take the extra step that makes it real: the rules become parameters the deployment reads, denials the platform cannot ignore, and evidence a reviewer can inspect.
A document the system has never read.
WHY POLICIES FAIL
An AI policy usually fails in one of three ways. It is written in language no configuration could express. It is implemented as an application setting somebody can switch off. Or it is enforced somewhere nobody can inspect, which for a security review is indistinguishable from not existing. The fix for all three is the same: write the rule so it can be enforced, then enforce it where it cannot be quietly undone.
Enforced by the platform
Procedural control
Not enforceable today
Your policies, applied in the system. Not a PDF, not a black box.The difference this page describes
Six rules, in language a system can hold.
WHAT WE HELP YOU WRITE
We bring the questions and the vocabulary; you bring the decisions. Where you already have a policy we work from it rather than replacing it, and we say which clauses can be enforced and which cannot.
02
What data may reach a model.
The classification line: which categories may be sent for inference, which may only be summarised, and which must never leave a system of record. This is the rule the content policy is built from.
03
Which models for which work.
A frontier model for drafting, a smaller one for classification, nothing at all for the zero-error path. Decide it deliberately: the allowlist is a deploy-time parameter, so changing it is a release rather than a preference.
04
Retention and residency.
How long conversations, documents and audit records are kept, and where inference may run. Residency is a real choice with a real capability cost, and the rule should be written knowing that cost.
05
Who may build and promote.
Who authors a capability, who approves one into production, and what is written down when they do. In a small organization that is one person plus a rule about recording why, which is better said plainly than dressed as separation of duties.
06
Disclosure to people affected.
When someone is told a model shaped what they are reading or a decision about them, what it was used for, and how to challenge it. We can help you write the standard. It is a commitment you are making, not a feature the product enforces today.
Each rule, and where it actually bites.
POLICY · ENFORCEMENT · VERIFICATION
This is the table we build with you, and the third column matters as much as the second. A control you cannot demonstrate is one your reviewer has to take on faith.
| Policy statement | Where it is enforced | How you would verify it |
|---|---|---|
| Every AI request is checked against our content rules | ✓Content policy, mandatory on every inference call, enforced by cloud identity policy as a deny | It is not an application setting, so there is nothing to switch off. The policy is a pinned, numbered version, so what applied last quarter stays identifiable. |
| Only approved models may be used | ✓Model allowlist, checked when models are listed and again when one is invoked | Ask an administrator to add a model. They cannot: the allowlist is a deploy-time parameter changed through a release, not from inside the running system. |
| No request may bypass the governed route | ✓Denied in cloud identity policy, alongside inference outside the configured regions | Tests fail the build if one of these denies is weakened, and the resolved controls are shown to you inside the product on the plan page. |
| Our prompts are not used to train models | ✓The default retention posture, plus a deny on widening the account's retention election | The frontier tier that requires provider-side data sharing is shown as unavailable until you elect it explicitly. It is never a silent upgrade. |
| Inference stays inside our region | △Residency pin on the Strict posture, with a request-time refusal in words | Ask for a model with no route inside your region and read the refusal and its reason. Nothing is silently rerouted. The cost is real: every current frontier model routes outside Canada. |
| People get only what their role allows | ✓Roles as identity groups with runtime-editable grants, and an access matrix | Read the matrix, change a grant, and find the change in the audit record. Nothing in the running system can create a role. |
| Nobody puts a capability into production alone | ✓Administrator-only promotion, pinned to an exact artifact hash | Read the promotion record: who approved, which hash, and the verbatim justification where a single-administrator deployment self-approved. Our automation has no promote route. |
| Use is bounded per person | ✓Per-person token quotas that fail closed | Usage by person is in the administration area. A failed settlement deliberately overstates rather than understates. |
| An administrator reading someone's chat is recorded | ✓The read is itself written to the audit record | Find the read in the record. Model invocation logging carries model, caller, latency and token counts, and no prompt or answer text. |
| Only people cleared for a document may retrieve it | ✕Not enforced at retrieval today | Procedural: everything loaded into a deployment's knowledge base is readable by every user of it. The control is what you choose to load. |
Where the second column says part or no, that is the verdict as it stands today and not a roadmap hint. The full mapping of technical controls to recognised criteria, each with an enforced, partial or not-enforced verdict, is on compliance alignment.
Procedural controls, named as such.
WHERE A RULE CANNOT BE ENFORCED
Some rules cannot be held by the system. Calling those procedural is not an excuse: it is a decision that has to be written down, assigned to a person and reviewed, because a procedural control with no owner is a wish.
- 01Per-document access in the knowledge base. There is no query-time permission filter and no permission labelling at ingest. Everything loaded is readable by every user of that deployment, so the control is what you load. In practice: a curated corpus with a named content owner, and sensitive material handled by a capability with its own permissions instead.
- 02Redaction and prompt-injection defence. The policy engine supports denied topics and personal-information rules, configured per client rather than on by default. They are controls you tune, with the outcome depending on how you tune them.
- 03Grounding and citation quality. The assistant returns citations and declines when retrieval finds nothing, after retrying with alternative phrasings. Citations are not independently validated, there is no groundedness score, and PDF is the only supported format today.
- 04Notice to affected people. There is no standard end-user notice built into the product. If your policy requires one it is a process you own, and we will help you write it.
- 05Attestation. Designed to align with SOC 2 and ISO/IEC 27001, providing the technical controls that support your program. We hold no third-party attestation, and we say so in writing, including inside the questionnaire we ask you to sign.
Where the rest of this is written down
The whole list lives at what we do not claim, and your own deployment shows you its standing exceptions inside the product rather than in a document we control.
A questionnaire, not a workshop.
THE INSTRUMENT
Published before the call
The questions are the method.
The security posture questionnaire is how the advisory work actually happens. It is written for IT directors, CTOs and security reviewers, explains tradeoffs honestly, and never assumes a requirement without asking. What comes out of it is the configuration the infrastructure reads.
- 01It produces a resolved posture. A tier, plus every override with the reason it exists and who approved it. Downgrades carry a disclosure.
- 02The same object builds the infrastructure and the plan page. A test fails the build if the deployed state and the page disagree, so the evidence cannot drift away from the system.
- 03It is published. You can read every question, including the one that asks whether you understand we are not certified, before you ever speak to us.
Seven sectionsPosture
- 01Organization context and the AI tools already in use
- 02Residency, with the tradeoff disclosure stated before you choose
- 03Security controls: encryption, identity, audit, network
- 04Operational requirements
- 05Your compliance program, and what you expect of us
- 06The posture recommendation
- 07The commitment, with overrides recorded
Walked in the assessment·Committed before the deploy
Alongside your advisors, not instead of them.
COUNSEL · AND QUESTIONS
Scope of this work
This is not legal advice and we do not present it as any. We are engineers who can tell you where a rule will be enforced, how it can be demonstrated, and what it costs in capability. Your counsel decides what your obligations are, your privacy officer decides what is acceptable under them, and we are glad to sit in those conversations and answer the technical half. Where a clause cannot be enforced in the system, we say so in front of everybody rather than letting a document imply otherwise.
01Can we buy the advisory work on its own?
Written rules are only worth what enforces them, so this is part of an engagement rather than a standalone product. The strategic assessment does include the posture questionnaire and a recommended tier with reasons, and you keep that whether or not you proceed.
02We already have an AI policy. Do you rewrite it?
No. We read it and mark each clause: enforceable in the system, enforceable as a procedure with a named owner, or not enforceable as written and here is why. Then you decide. Most policies survive largely intact and gain a few sentences that make the vague parts checkable.
03Who can change a policy after we go live?
Not an administrator from inside the running system. The content policy, model allowlist, posture tier and residency are deploy-time parameters, so changing one is a release with a new pinned version number. Grants, roles and quotas are runtime-editable, and those changes are written to the audit record. That split is deliberate.
04Does this get us through a customer security review?
It gets you the technical half in a form a reviewer can inspect: the resolved posture with its exceptions, the controls matrix with its verdicts, the architecture record, and the deployment's plan page. It does not get you an attestation. See the evidence pack.
05What happens when a rule and a capability conflict?
The rule wins and the capability is refused. The most common version is residency: a policy pinned to a region, and a model the business wants that has no route inside it. The request is refused with a reason rather than quietly rerouted, and then it is a business decision made with the facts in front of you.
⎯⎯ Book the strategic assessment ⎯⎯
Your private AI, inside your control ·
The assessment walks the posture questionnaire with you and produces the recommended tier, with every exception written down.