Access & permissions
Define who can see data and take each action.
Infrastructure & Governance
The confidence to keep it running.
Give AI systems an operating foundation: access controls, evaluations, logs, cost visibility and a clear response when something goes wrong. Core controls belong in every build.
Signals this is the right service
You will recognise
at least two of these.
You will recognise some of these in your own business.
Two or three AI tools are already in use and nobody can say which records each one can read.
A prompt or model was changed last month and nobody checked it against real past cases first.
The monthly usage bill arrives as one number that cannot be attributed to a team or a workflow.
When an output was wrong, the team heard it from a customer rather than from a report.
An auditor or a large client asked how AI decisions are recorded, and the answer took a week.
What Infrastructure & Governance is
See who can use it, what it did and what it costs.
This is the operating foundation underneath an AI system: who may use it, what it may do, how a change is checked before it goes live, what it costs to run, and what happens the day it gets something wrong. Every system BYBO builds carries these controls already. This service is for businesses needing one shared foundation across several systems, or across work built by someone else.
The work is unglamorous and specific. We name an owner for each system. We write permissions by role, so a person sees the records and takes the actions that match their job and nothing wider. We assemble an evaluation set from real past cases and run it before every release. We turn activity into readable logs and a cost view, and agree a response plan for failures.
What stays with your people is judgement and authority. The controls decide nothing on your behalf; they make decisions visible and reversible. Your release owner approves changes. Your named operator watches quality and cost. If you later change vendor, model or team, the permissions, evaluations and records remain yours, as how we work sets out.
A worked example
The screen your
auditor asks for.
Who could act, what ran, what it cost, what was blocked, and who signed off the last change.
The record
19 Sep 14:02
Release blockedPrompt change · refunds
evaluation failed18 Sep 09:20
Action takenRefund issued ₹2,400
approved by Divya17 Sep 16:44
Access deniedSupport role · payroll data
outside permissions16 Sep 11:07
Release approvedRetrieval index rebuild
signed by Divya1,284 actions this month11 blocked₹—— spend, shown in your currency
Not a report someone assembles at quarter end. The log is the system, written as the work happens.
What the system did
Recorded 1,284 actions with the person or system behind each
Blocked 11 attempts that fell outside a role’s permissions
Held the 12 September release until its evaluation passed
One release did not go out.
A prompt change on 19 September failed two of the forty cases in the evaluation set, both on refund wording. It stayed unreleased. The evidence, the failing cases and the rollback point are all in the record.
Waiting on a person
Divya, Release OwnerEvaluation report attached · rollback point recorded
Approve anywaySend back to buildCost sits beside quality
Spend per workflow is in the same view, because a system that is accurate and unaffordable is still a problem.
Incidents have a path
Who is told, what pauses, how it is recovered — agreed in advance, not improvised.
It applies to existing systems
This can be put around AI you already run, not only what BYBO builds.
Illustrative example built to show the shape of the work. Not a client record.
Where it is used
Four shapes of
the same problem.
Most businesses start with one and add the second once the queue, the logging and the connections already exist.
Evaluation & releases
Check changes against representative cases.
Monitoring & costs
Track quality, reliability and usage together.
Incident response
Give failures a recovery path and an owner.
How the work runs
Five steps.
One of them is yours.
Every stage is recorded, so nothing is silently dropped or done twice.
- 01
Define
We agree policies, boundaries and a named owner for each system, including what it must never do without a person and which records are out of scope.
- 02
Control
Permissions and runtime limits go in by role, with caps on volume, spend and available actions. Access is reviewed on an agreed cycle rather than left to drift.
- 03
Evaluate
We build the evaluation set from your cases and agree the pass mark with the people who do the work. A cheaper answer that is wrong is not cheaper.
- 04
Approve
A named release owner authorises each production change against the agreed checks, with a rollback path tested before it is needed rather than after.
- 05
Observe
After launch we monitor quality drift, failures, availability and cost per task. Incidents follow the response plan, and what is learned joins the evaluation set.
Where a person decides
Release owners approve changes against agreed checks, with a rollback path.
The line is yours to draw, and we write it down before anything runs.
Release owners approve changes against agreed checks, with a rollback path. A change can be evaluated automatically, but it goes live because a named person read the result and said yes. The same holds in operation: high-impact actions wait for the reviewer named in the permissions map, and if nobody responds within the agreed time the work escalates rather than proceeding quietly. Responsibility is written down before you need it.
What you receive
5 things, and
they are all yours.
Not a demo and a slide deck. A running system, the evidence it works, and the documentation to run it without us.
A permissions map
A written table of roles: who reads which data, who triggers which action, who approves a release. Implemented in the systems, not only described.
An evaluation set
Real cases from your history, including awkward ones, each with the correct outcome recorded. Every change is scored against it before release.
Logs and an operating view
A readable record of what ran, what it decided, who approved it and what it cost, with quality, usage and reliability shown together.
A response plan
How a failure is detected, who is contacted, what pauses automatically, how you roll back and how the case is reviewed afterwards.
Documentation and handover
Plain-language notes on how the controls work and how to change them, plus a working session with the named owner and their deputy.
What you provide
5 things, and none
of them technical.
You do not need a developer. You need someone who knows how the work really happens, including the exceptions nobody wrote down.
- 01
A named owner for each system, with a deputy, and time in their week for reviews.
- 02
Real past cases, including the difficult and disputed ones, to build the evaluation set from.
- 03
The current rules: what is approved, what needs a person and what is prohibited.
- 04
Access to the accounts involved, at the level agreed rather than an administrator key.
- 05
A baseline for quality, cost and incident recovery today, even if the numbers are rough.
What it connects to
Built around what
you already run.
Controls are only real where the work happens, so we connect to your existing systems under permissions your team agrees in writing beforehand.
- Your identity and single sign-on provider, so roles follow the people you already manage
- Your cloud accounts and model providers, for usage and cost attribution
- Your existing AI systems and workflow tools, wherever they were built
- Your ticketing or service desk, so incidents arrive where the team already looks
- Your document storage, with read scopes limited to what is needed
- Your reporting tools, so the operating view sits beside the other business numbers
How it is judged
5 numbers, taken
before we build.
We record a baseline before anything changes, then review the same measures on an agreed cycle.
01
Evaluation pass rate on the agreed case set
tracked release by release
02
Incident recovery time
from detection to a working system
03
Cost per completed task
and how it moves as volume grows
04
Access and audit coverage: systems with a named owner and reviewed permissions
05
Share of releases that followed the approval path without an exception
What it costs
No price here,
and here is why.
The honest answer depends on your work and your systems. Scope and fee are agreed in writing before paid work begins, and the first conversation costs nothing.
BYBO publishes no prices, because the same words describe very different pieces of work. Scope and fee are agreed in writing before any paid work begins, and the first conversation is free. Where the picture is unclear, the sensible start is the Blueprint: a paid diagnostic ending in a recommendation and a 90-day roadmap.
Two costs behave differently. The build is one-off: assessment, controls, evaluation sets, documentation. Running costs continue: model and cloud usage, monitoring, and the hours your owner spends on reviews. Both are visible before you commit, and the cost view keeps the second honest. See the cost guide.
Once
Design and build of the system
Every month
Running it, the review time it still needs, and monitoring
Before you enquire
6 questions we
are asked every time.
Answered plainly, including the ones with an uncomfortable answer.
Discuss this systemWe already have an AI system built by someone else. Can you work on that?
Yes. We assess the architecture, permissions, failure handling and running costs as they stand, then set out what to fix first and what can wait. You get the assessment whether or not you ask us to do the remediation, and it is written so another team could act on it.
Does this make us compliant with data protection law?
No platform or vendor can promise that, and be careful of anyone who does. We implement the controls and evidence your security, legal and compliance owners specify, and make the records easy to produce when asked. The judgement about sufficiency stays with your advisers.
Will this slow our team down?
Reviews take time, so we scope them to match consequence. Routine work proceeds within agreed rules; changes and high-impact actions wait for a person. Most delay teams complain about comes from unclear ownership rather than the check itself, which is why naming an owner comes first.
What happens the first time it gets something wrong?
That is planned for rather than reacted to. The failure is detected, affected work pauses, the named owner is told, and you roll back. Afterwards the case joins the evaluation set so the same failure is caught before the next release. Nothing here assumes a system that is never wrong.
How much of our data do you need to see?
As little as the work requires. We prefer representative samples over full access, agree read scopes in writing before connecting anything, and keep access time-limited. Our handling of personal information is set out on the privacy page, and your security team can set stricter terms.
What is the first step, and who owns this afterwards?
A free conversation about one system you are unsure of: what it does, who uses it, what would happen if it failed on a Monday morning. Afterwards, everything is yours — the permissions map, evaluation set, logs and documentation. Start at enquire about this system.
Read more on this
Before you commit
to anything.
What Enterprise AI Governance Actually Means in Practice
Enterprise AI governance is not a policy PDF. It is a short set of working agreements, sized to the risk: who owns each system, what it may touch, what needs approval and what happens when it goes wrong.
Read the article
AI Permissions, Logs and Approval Gates: A Business Guide
Three controls decide whether an AI system stays inside its lane: a permission model, a log that can answer questions weeks later, and gates set to the consequence of the action.
Read the article
What Happens When an AI Workflow Gets Something Wrong?
Every AI workflow will get something wrong eventually. What separates a contained mistake from a damaging one is detection, a way to pause, an honest correction and a cause that actually gets fixed.
Read the articleBring us the system
nobody wants to be responsible for.
We will tell you whether it is worth building — including when it is not.