About
The Model Is Not The Problem
An AI assurance and governance firm based in India. Our premise: an AI system's risk is set less by how capable the model is than by what it has been permitted to do.
The Argument
Permissions Are The Constraint
Most conversations about AI risk are conversations about models - which one, how capable, how aligned, what it might say. It is the interesting question and it is largely not the one that determines what happens to you, because you did not build the model and you cannot inspect it.
What you did build is everything around it. Which credentials the agent holds. Which of its actions cannot be undone. Whether untrusted text can reach a privileged tool. Whether anyone has measured how often it is wrong, or could reconstruct what it did last Tuesday. All of that is yours, all of it is inspectable, and almost none of it gets attention until something goes wrong.
So we work from the boundaries inward. Red-teaming that tests what an agent can reach rather than whether a jailbreak string gets through. Eval sets built from your data, wired to fail a build. Policy expressed as approval gates and scoped credentials rather than as a PDF. Tracing deep enough that an incident is a thing you read rather than a thing you argue about. And cost measured per outcome, because a system nobody can afford to run gets switched off regardless of how good it is.
Assume the model will occasionally fail. Then make sure that when it does, what it can reach is small, reversible, visible and recorded.
How We Work
Four Stages, In A Loop
Every engagement runs the same spine. The important detail is the last step: a cycle ends back at the diagnostic, not at onboarding - because systems change, models get swapped and somebody always adds a tool, so a picture taken once goes stale fast.
01
Audit
A read-only diagnostic of what you run today: every AI system in use, what each can reach, where untrusted input can get to a privileged action, what data leaves, and whether anything is measured or recorded. It ends in a written roadmap ordered by risk.
02
Instrument
We build the things that have to exist before anything else can be judged - tracing through model and tool calls, an eval set from your own data, and the system inventory. Nothing here is a product of ours; it is built in your stack and stays there.
03
Govern & Operate
Controls go live - scoped permissions, approval gates on irreversible actions, alerting, regression gates in CI. Every week you get what changed, what the numbers did, and what we would do next. Controls that are not delivering value are removed.
04
Re-audit
Each cycle ends back at the diagnostic rather than at onboarding. Systems change, models get swapped, someone adds a tool - so what the last cycle established becomes the baseline for the next one, and the picture compounds instead of going stale.
Independence
Independence And Limitations
The boundaries of our role, stated up front so they can be relied on in procurement and contract review.
We do not certify
Vetro is not an accredited auditor or certification body. We prepare the inventory, controls and evidence that ISO/IEC 42001 and EU AI Act obligations call for, so that an independent certification audit can rely on records that already exist. Keeping preparation separate from certification avoids a conflict of interest.
We do not guarantee outcomes
Prompt injection and hallucination remain open problems across the industry. Adversarial testing establishes whether specific attacks succeed against a system as it is configured at the time of testing; it is evidence, not proof that no vulnerability exists. Findings are reported on that basis.
Every finding is evidenced
Each finding is reported with the path we followed, the impact we were able to demonstrate, and a recommended remediation. Where a finding does not warrant remediation, the report says so.
No commercial interest in what we recommend
We take no commission, referral fee or reseller margin on any tool, model or platform we recommend, so a recommendation is never influenced by what it earns us.
No unverified claims
Figures on this site are service commitments, not reported results. Client names and outcomes are published only with the client's written consent.
Engagement Model
Founder-Led Delivery
Every engagement is led directly by the founder, from the initial audit through implementation. There is no hand-off from the people you speak to before signing to a delivery team you have not met.
Work is carried out inside your own environment and repositories, with read-only access by default, and everything we build remains yours. Access, data handling and rules of engagement are agreed in writing before any work begins - see Trust & Security.
Founder
Prithviraj Chawla
Start With The Audit
Read-only, at no cost and under mutual NDA. It changes nothing in your systems, and the written roadmap is yours whether or not you engage us further.