AI GOVERNANCE
Your team is already using AI.
Can you prove it is under control?
We build software with AI ourselves, our engineers use AI coding assistants on client work, and the systems we build carry AI components where a benchmark says they earn their place. Both run under a written operating model with measured outcomes. This page shows what that looks like in practice, so you can check it before you work with us.
THE PROBLEM WE ARE USUALLY CALLED FOR
AI adoption rarely starts with a decision. It starts with a tool.
An engineer picks up a coding assistant. A team wires a model into a workflow. A feature ships with AI behind it. By the time leadership looks, AI is already in the product and the pipeline, usually before any policy, cost control, data rule, or quality gate is in place. That gap is where the risk lives.
Shadow AI
Tools and data flows nobody approved, and nobody can see.
Data exposure
Customer data reaching tools that were never cleared to handle it.
Vendor lock-in
A product that quietly cannot run without one AI provider.
Uncapped spend
Costs that can spike without warning, with no ceiling and no shut-off.
Unclear accountability
AI assists the work, but nobody is clearly responsible for the outcome.
START WITH ONE BUILD
One AI capability, built into your product or pipeline.
A team of RBT engineers builds one capability in your product or pipeline, with the scope agreed before work starts. It starts with a short design phase inside the build, so what we build fits your architecture and your gates. The same team can carry on afterwards.
What we build:
- A model-neutral AI layer with a fallback path, so the product keeps running if a vendor changes its price or terms
- An AI feature with a human approval step, where a person accepts every customer-affecting result
- Spend control for AI features and tools: caps, alerts, and automatic shut-offs
- AI coding assistants behind the same CI and review gates as human code, with approved tool configuration and secret scanning
- Data routing enforced in the pipeline, so each class of data reaches only the tools allowed to see it
HOW WE USE AI IN OUR OWN DELIVERY
Our engineers use AI assistants. The gates do not move.
The rules are written into an AI usage policy that our head of engineering owns and reviews at every governance gate, and whenever a tool or vendor changes. The four that matter most to a client are below, and the policy itself is published on the blog.
Same gates for AI and human code
An AI-drafted change passes linting, strict type-checking, the full test suite, an automated reviewer, and human review like every other change. Security-sensitive areas get senior review, and the tools used are noted in the pull request.
Every tool on an allowlist
Engineers use approved assistants only. A tool that isn't on the list goes through a documented request, and the head of engineering decides within two weeks, together with the tool administrator who checks the vendor's data terms.
Code, never customer data
Development tools sit in the internal data tier: source code, architecture documents, and tickets. Customer data and production secrets never enter a prompt, and browser AI extensions are not allowed.
Measured, not claimed
A baseline before adoption, and outcome metrics at fixed gates. Every assistant seat is a per-person plan on the central bill. A seat unused for a full period between gates is removed at that gate.
HOW WE PUT AI INTO WHAT WE BUILD
Six questions we answer on day one for our clients' products, and our own.
What happens if the AI vendors disappear?
Nothing breaks. AI is an accelerator, never a load-bearing wall: the product runs without it, models swap by configuration, and developer tools affect speed, not whether the software works.
Whose cloud holds our data?
Yours. Data is classified into tiers and routed only to the tools allowed to see it. Developer tools see code, never customer data.
Who approves what the AI decides?
A person, on every customer-affecting decision. In a document-processing feature, the reading is automated and the acceptance is human, and the figure we report is how much the reviewer had to correct, per document type.
Which models, and why those?
The output of a benchmark on your own accuracy and cost criteria, commercial against open-weight, re-run at each gate. Managed models on Amazon Bedrock and smaller language models both appear in what we build; a paid model is chosen only where measured quality justifies it.
Is every dollar capped before it is spent?
Yes, per seat and per feature, with alerts and automatic shut-offs. A price shock shifts the economics gradually; it cannot blow a hole.
Are we measuring, or chasing hype?
A written plan, a measured baseline, and 30- and 90-day gates with go or no-go criteria.
WHY RBT
Governed AI adoption, built from real engineering.
The operating model on this page is the one we run on our own delivery, and our teams build and run the systems it requires.
What we deliver is the engineering: the controls, the architecture, and the evidence they produce.
Most AI-governance advice comes from firms that never ship software. RBT is a software engineering company. Our governance is built from how we actually deliver: model-neutral architecture, capped spend, data classification, human accountability, and quality gates that don't relax because AI was involved.
The operating model on this page is the one we run on our own delivery, including the honest parts: measured outcomes before any claim, no vanity metrics.
Model-neutral architecture, capped spend, data classification, human accountability, and quality gates that do not relax because AI wrote the code.
FIND YOUR SITUATION
Where do you need control before you scale?
| If this is happening | RBT helps with |
|---|---|
| You are shipping AI features but cannot say where customer data goes | Data classification and routing enforced in the pipeline |
| Your product quietly depends on one AI vendor | Model-neutral architecture and fallback design |
| Your engineers use AI tools with no shared rules | Enforced tooling, guardrails, and review gates |
| AI spend is a mystery | Cost caps, alerts, and automatic shut-offs |
| AI-assisted work has unclear ownership | Human accountability model and review gates |
HOW RBT HELPS
Start with a conversation. Most teams move into building.
A conversation
Tell us what you build and where AI sits in it today, or where you want it to.
A fixed-scope build
A team of RBT engineers builds one AI capability in your product or pipeline, starting with a short design phase inside the build.
Build and run
The same team carries on, building what comes next and maintaining what it built.
WHAT WE DO NOT CLAIM
The honest list.
No percentage of AI-written code, ever.
It rewards verbosity and says nothing about quality or risk.
No productivity number until the measurement period delivers one.
The baseline is captured; the gain is reported at the gates.
No AI-versus-human defect comparison yet.
The baseline answers the question that actually matters, whether quality regresses, at the 90-day gate.
WHAT YOU CAN CHECK
Read it, then check it.
RBT has held ISO/IEC 27001 certification continuously since January 2017, covering software development, embedded development, and DevOps.
Running AI under governance is the full operating model behind everything on this page: the architecture, the spend controls, the data classification, the quality gates, and the exit ramps, written to be usable without engaging anyone. It is sent to one address once you confirm it, and it costs nothing.
IN PRACTICE
CTO writing on AI governance and engineering
Read our CTO's perspective on how AI adoption should be governed across product and engineering, from board-level questions to what actually happens inside the codebase.
FAQ
How does RBT use AI in software development?
Engineers use approved AI coding assistants on client work under a written AI usage policy owned by the head of engineering. An AI-drafted change passes the same gates as any other change: linting, strict type-checking, the full test suite, an automated reviewer and a human review, with senior review on security-sensitive areas. The tools used on a change are noted in the pull request.
Does RBT put AI into the products it builds?
Yes, where a benchmark on the client's own accuracy and cost criteria says it earns its place. Product AI runs behind a model-neutral interface so the model changes by configuration, the product works without it, a person approves every customer-affecting decision, and each feature has a capped monthly budget. Managed models on Amazon Bedrock and smaller language models both appear in what we build.
Where does customer data go when RBT builds with AI?
It stays in the client's own cloud account. Data is classified into four tiers and routed only to the tools permitted for each tier. Development tools see source code, never customer data, and no provider trains on it.
What does a first build with RBT look like?
A team of RBT engineers builds one AI capability in your product or pipeline, with the scope agreed before work starts: for example a model-neutral AI layer with a fallback path, an AI feature with a human approval step, spend caps with automatic shut-offs, AI coding assistants behind your CI gates, or data routing enforced in the pipeline. It starts with a short design phase inside the build, and the same team can carry on afterwards.
Does RBT advise on regulation or certification?
No. RBT is a software engineering company. What we deliver is the engineering: the controls, the architecture and the evidence they produce. Legal and regulatory questions stay with your own counsel.
What is in the Running AI under governance operating model?
A written operating model for adopting AI in a software organization: model-neutral architecture so no single vendor is load-bearing, capped and attributed AI spend, a data classification that says what may reach a third-party model, quality gates for AI-assisted code, exit ramps, and the evidence an enterprise customer or acquirer asks for. It is the model RBT runs on its own delivery.
How do I get the operating model, and does it cost anything?
It is free. Enter an address on the AI governance page and confirm it from the email that arrives; the document is then sent to that address as a private link that works for seven days. Nothing is sent and nobody makes contact before the address is confirmed, and an address that is never confirmed is deleted.
Can I read RBT's AI governance thinking without giving an email address?
Yes. The operating model is published as a full article on the RBT blog at rbt.rs/blog/running-ai-under-governance-operating-model/, which requires no address and is open to read and to cite.
GET STARTED
Tell us what you are building.
One fixed-scope build is the usual way in, and the same team carries on from there.