Fifteen years building AI systems that ship
I have built regulated AI systems myself, repeatedly, and learned where they break. Now I advise the organizations doing it.
Vikram Jha — Defensible AI is an independent practice. Independent is a claim about neutrality, not about headcount: assurance work is only worth anything if the person doing it has no stake in the platform being assured. I hold no ownership interest in any platform I assure for a client, and the one adjacent interest I do hold is disclosed below and in the conflicts policy.
Delivery runs through me plus a standing network of senior engineers I have shipped with before. You are not buying a bench of juniors with a partner’s name on the cover — the person who scopes the work does the work.
Background
I led an international team on humanoid autonomy in a field-robotics program, where the systems had to work in conditions that forgave nothing: no controlled lighting, no reliable comms, no second attempt. The judgment formed there — about what autonomous systems do when reality disagrees with the plan — is the foundation of the governance work I do today.
Since then: production AI across financial services, insurance, healthcare and regulated industry, in the United States, India and Europe. Founder-side and advisory-side both.
Also currently
I am co-founder of an AI infrastructure company, in stealth, building the authorization layer that decides what an agent is permitted to do, enforces it at the point of action, and produces an evidence record designed for review.
I also co-found a separate company working on agent authorization. That creates a potential conflict, and I disclose it before an engagement is agreed. This practice holds no ownership interest in any platform it assures for a client, and does not sell, recommend or implement an affiliated product in client work. Scope, safeguards and any need for an independent reviewer are agreed in writing. I do not discuss specifics publicly beyond that disclosure. If you are working on agent governance at an enterprise or as a research group, I am glad to go deeper under NDA.
The independence register
No product recommendation
Every deliverable produces requirements, evaluation criteria and evidence gaps. It never names a preferred vendor or routes a client toward an affiliated product.
No solicitation
The advisory practice does not solicit the client for an affiliated product during the engagement or use the engagement as product discovery afterward.
Hard data boundary
Client advisory material does not enter the product company, its systems, product roadmap or training data.
Disclosure before conflict
A potential organizational conflict is disclosed before work begins. If a client reasonably needs the company identity under NDA for diligence, it is disclosed before contracting.
Client termination right
The client may terminate for cause if a conflict is concealed, the data boundary is breached, or advice is used to steer a product decision.
The full text, with the conflicts policy, is at /independence.
How I work
- A small number of engagements at a time. Depth is the product.
- Written output your risk function can take to a committee, not a slide deck.
- I will tell you when the answer is that you do not need me.
- Remote, across United States, India and Europe hours.
What this site keeps about you
The same inventory /privacy publishes, rendered from the same source. A practice that sells governance should be able to answer its own questions.
| What | Why, and when it is recorded | Processor | Retention |
|---|---|---|---|
| Diagnostic scores — four layer scores, sector, jurisdiction, action class, volume band | Recorded when you complete the diagnostic, to build a sector benchmark. No organization name, email, identifier or IP address is stored with the row. | This site's own database (managed Postgres) — table diagnostic_runs. | Kept indefinitely. There is no scheduled deletion job on this table. This row said "24 months" until 9 September 2026; nothing in the code enforced it, and the only automatic deletion anywhere in this database is a 24-hour purge of rate-limit counters. The rows carry no identifier, so there is nothing in them to erase on request — which is why a duration was never built, and not a reason to have published one. |
| Inquiry details — name, email, organization, situation, timeline | Recorded only when you submit the contact form, to respond to you. This is the only place identity is attached, and you attach it deliberately. | This site's own database (managed Postgres) — table inquiries. Forwarded to the practice principal's mailbox so the inquiry can be actioned. | Kept until you ask for erasure. There is no scheduled deletion job on this table — see "One retention rule" on the privacy page for what that means in practice. |
| Subscriber email | Recorded only if you subscribe, to send new writing. | This site's own database (managed Postgres) — table subscribers. | Until you unsubscribe. |
| Diagnostic delivery email — address, sector, overall score band | Recorded only if you ask for the diagnostic PDF by email. Sent with the generated PDF to Resend for delivery, and stored as a contact record so a conversation can follow. Held separately from the anonymous diagnostic row above; the two are never joined. Choosing Print or save as PDF instead sends nothing anywhere. | This site's own database (managed Postgres) — table report_requests — for the contact record; Resend for delivery. | Kept until you ask for erasure in the database. Resend's side is a separate path — see "Email-provider logs" below. |
| Teardown request — name, email, organization, the link or file you send, your notes | Recorded only if you request an asynchronous teardown, to read the artifact and write the critique back to you. | This site's own database (managed Postgres) — table teardown_requests — for the request fields. An uploaded file is forwarded to the practice principal by email and is not retained in the site's storage; only its filename and size are recorded, so the request can be tracked. | Request fields: kept until you ask for erasure. Attachment: not retained here after forwarding — see "Mailbox" and "Email-provider logs" below for where a copy may persist. |
| Anonymous usage events — page viewed, diagnostic started/completed, per-question progress and time bucket, article read depth, time-on-page bucket, page performance numbers, error counts, booking link clicked, form submitted | Recorded as you use the site, to see which pages are useful, where people give up, how far articles are read, how fast pages load, and which article preceded a diagnostic. Configured with memory-only persistence, manual bounded events, no autocapture, no session recording, no person profiles. Every property leaving the browser is a bounded category or a number — no form values, answers, organization names, email addresses, free text, URL, referrer, search term or user-agent string. Durations are reduced to four coarse buckets before capture. See src/lib/analytics.ts for the complete, typed list of events. | PostHog, via this site's first-party proxy. | 12 months. |
| IP address ($ip, attached by the analytics pipeline to every event) | PostHog treats an absent or empty $ip as an instruction to use the address on the connection, so a value has to be sent for the address not to be used. This site sends the fixed placeholder "0" on every event (src/lib/analytics-privacy.ts). A client-side sentinel alone is not the full control: the authoritative one is the PostHog project's own "Discard client IP data" setting, which PostHog documents as the only way to stop the fallback for every ingestion path, including ones this repository does not send events through directly. Both are meant to be in force (docs/posthog-privacy-settings.md). | PostHog. Sentinel applied client-side in src/lib/analytics-privacy.ts; discard setting applied in the PostHog project. | Events captured from 18 August 2026 onward: 12 months, with the other usage events above. Events captured 24 July – 17 August 2026, before the fix, carried a real address and derived location instead of the placeholder: open — see the dated status on the privacy page. |
| Rate-limiting digests — salted SHA-256 hashes derived from the requesting network address and, where a form supplies one, the email address and its domain | Written when a public form or report endpoint is called, to enforce a narrow request limit. Each value is salted and one-way hashed before it reaches storage, so no address, email or domain is recoverable from a counter row. A row holds a digest, a token count and a timestamp — nothing else. These are pseudonymous derived identifiers, used to count repeated requests without storing the original value; they are not a claim that the original cannot be recovered under every threat model. Counters are never joined to form or diagnostic records and are not used to recognize a returning visitor. | This site's own database (managed Postgres) — table rate_limit_buckets. | Deleted once the counter has refilled and can no longer deny anything — at most 24 hours. The only table in this inventory with a code-enforced deletion (src/lib/db.ts). |
| Referrer tag — e.g. utm_source=article | Stored alongside the records above, to know which page led somewhere useful. | This site's own database (managed Postgres), attached to the record it belongs to. | With the record it belongs to. |
| Mailbox — the practice principal's own email inbox | Receives a notification when an inquiry or teardown request is submitted, and carries a forwarded attachment where a teardown request included one. | The practice principal's own email provider — outside this application's database. | Not established in code. Governed by the principal's own mailbox retention, not by this application. |
| Email-provider logs — Resend's own delivery and operational logs | Deliver the diagnostic report PDF and the forwarded notifications above. | Resend. | Resend's own operational email-log retention. Not set by this application. |
| Database backups | Disaster recovery for the application records listed above. | The database hosting provider. | Not established in code. Governed by the hosting provider's backup policy, not by this application. |
If any of this is live for you
The fastest route is a conversation. Bring the architecture you are worried about — the first useful thing usually surfaces inside twenty minutes.