Which models touched our code, and who approved them?
A governed decision per engagement, constrained to an approved set and recorded.
Approved modelsGovernance that survives an audit.
Three questions a risk committee asks.
What stopped the system doing something it should not have?
Guardrails built into every AI feature as code, defined before build.
GuardrailsCan we produce evidence when an auditor asks?
Prompts, context, outputs and the engineer who accepted each change, retained.
What you can inspectApproved models, named providers, recorded decisions.
Client work runs on approved models from Anthropic, Google and OpenAI under enterprise terms, never on consumer endpoints and never on an engineer's personal account.
Enterprise termsClaude
Approved provider
Anthropic
Enterprise termsGemini
Approved providerGoogle
Enterprise termsGPT
Approved provider
OpenAI
Guardrails built into the feature, not written around it.
Every AI feature carries a defined control set before a line of it reaches a client environment. The controls are code, not a policy document describing them.
Input controls
What the feature accepts, and what it rejects before it reaches a model. Injection resistance is designed at this boundary, not patched after a finding.
Output constraints
What it may return, in what shape, and what happens when a response falls outside it. Nothing reaches a downstream system unvalidated.
Tool and permission scope
What it may call, with what credentials, and what it is explicitly denied. Defined at build time and enforced at runtime.
Escalation paths
What it does when it is uncertain, and which human it routes to. A feature with no defined escalation path does not pass audit.
A certified architect owns guardrail design on every AI feature and signs the audit that releases it. Certification is a prerequisite for that sign-off, not a preference.
Claude Certified Architect, Anthropic
No AI feature ships without an AI architecture audit.
A formal architecture audit before release, conducted by a certified architect who did not build the feature. A feature that does not pass does not ship.
-
01
Model and data flow
Which model, which provider, what client context reaches it, what is retained and where.
-
02
Guardrail coverage
Controls present, tested and enforced at runtime rather than declared.
-
03
Failure behaviour
What the feature does when the model is unavailable or returns something outside its permitted scope.
-
04
Permission and identity
What credentials it operates under, and whether its scope exceeds what its function requires.
-
05
Evidence and traceability
Whether its activity can be reconstructed after the fact, and by whom.
-
06
Regulatory fit
Whether its behaviour holds up against what governs software in the client's industry.
-
Release
Reached only when every checkpoint above has passed.
When a feature does not pass
It returns to build with named findings and is re-audited before release. There is no override path and no exception process, which is the only thing that makes the gate meaningful.
What the client can inspect.
Governance that cannot be examined is assurance. These artifacts are available to a client on request, and to their auditors.
Which model was selected, by whom, on what basis, and when it changed.
What was sent to a model, drawn from which client sources, for every AI-assisted change. Retained for the life of the engagement and available on request.
Which named engineer accepted each change, and at which gate.
The control set defined for each feature, and the tests that prove it holds.
The audit result for every feature, findings raised and how they were closed.
What client context may reach a provider, agreed in writing before the engagement.
Governed against
NIST AI RMF
ISO/IEC 42001
OWASP LLM Top 10 (2025)
OWASP Agentic Top 10 (2026)
MITRE ATLAS
Security testing against these frameworks is covered on the Security and Compliance page.
Start with a governance readiness review.
A review of one AI feature or one delivery process against the audit checklist above. It returns named findings and a specification for closing them. No fee for the first review.
What Winjit needs to run it
Book a governance review
Access to one AI feature or one delivery pipeline, and a conversation with whoever owns it. The same audit applies to features already in production, whoever built them.
Questions risk and security teams ask.
Approved models from Anthropic, Google and OpenAI under enterprise terms. Model selection is a recorded decision made once per engagement and constrained to the approved set. Consumer endpoints and personal accounts are not permitted.
No. Client code and data are not used to train provider models. Client work runs under enterprise terms that exclude prompts and outputs from training, and the applicable terms are shared during a vendor review.
A named engineer accepts every AI-assisted change at a defined gate. Accountability sits with that person and is recorded against the change.
Yes. Model decision records, prompt and context logs, acceptance records, guardrail specifications and audit findings are available to clients and their auditors.
Yes. The same audit and guardrail standard applies to features already in production regardless of who built them, including an evidence trail built retroactively where none exists.