Trusted AI: Guardrails, Governance, and Proof That Your Team Still Owns the Work

Your team is already using AI.  You may have noticed it first in a code review, when a pull request came back looking nothing like how that developer writes.  That moment is the real starting line, and most teams hit it before anyone has written a policy, picked a tool, or decided who is accountable for the result.

This session covers what an agency put in place after running that experiment across half a dozen development pods, and what held up under client work in Drupal and WordPress.

You'll see the layers in order, because they only work in order:

• Policy before tooling.  An internal policy for your team and an external one your clients can read, including which tools are approved based on whether the vendor trains on your input.
• Training that isn't optional even when the tooling is.  Nobody gets forced to use AI.  Everyone gets taught how to review what comes out of it.
• Guardrails in the repository.  AGENTS.md and CLAUDE.md files that cascade from a single folder up to the whole organization, so the agent knows your coding standards, your test suite, and what has to pass before a merge.
• Skills that capture the work you repeat.  and Commit messages, pull request templates with validation steps, single directory component conversions, migration scaffolding.
• Proof that a human reviewed it.  Moving from a checkbox on a pull request to a delivery record that names the reviewer and the checkpoints, plus a commit trail showing which agent assisted.
• Adversarial testing for the AI features you ship to editors and site visitors.  Prompt disclosure, instruction override, token exhaustion, and the uploaded image with instructions written on it that a Drupal site happily followed.

That last layer is where most teams have nothing.  If you build an AI summary into search or a drafting assistant into your editorial workflow, someone will try to break it, and the ways they break it are new.

Attendees leave with the four questions Kanopi uses to judge whether AI work can be trusted, a starting checklist for their own policy and guardrails, and links to open source skills they can install the same afternoon.

What attendees will learn

1. How to write an AI policy your team will actually follow, and why it needs rewriting every few months.
2. Where guardrails belong in a Drupal or WordPress codebase, and what goes in each level.
3. How to turn a task you keep repeating into a skill, test it, and hand it to the team.
4. What an attestation trail looks like, and how it protects you when a client asks how their code was written.
5. How to red team an AI feature before your site visitors do.