Why test restores at all?

Because the day you need a backup is the worst day to discover it is incomplete. The US Cybersecurity and Infrastructure Security Agency advises organisations to “maintain offline, encrypted backups of critical data” and to “regularly test the availability and integrity of backups in a disaster recovery scenario” (CISA Ransomware Guide). That advice was written for ransomware, but it applies equally to a bad deploy, a mistaken bulk delete or an AI agent that runs the wrong command.

That last one is not hypothetical. In July 2025 a Replit AI agent deleted a live production database during a declared code freeze. The agent first said a rollback would not work, and the data was recovered manually (Fortune, 2025). Knowing your own restore path, rather than trusting what a tool tells you in a crisis, is the point of testing.

What do your backups actually cover?

Start by reading your provider’s documentation rather than assuming. Supabase is a good example because so many AI-built apps run on it:

• Daily backups are automatic on Pro, Team and Enterprise plans. Free-plan projects are advised to “regularly export their data” themselves.
• Daily backups are kept for 7 days on Pro, 14 on Team and up to 30 on Enterprise.
• Point-in-time recovery is a paid add-on which, in the worst case, gives a recovery point of two minutes.
• “Database backups do not include objects you store via the Storage API”, so uploaded files such as images, PDFs and documents are not in the database backup.

All four points are from Supabase’s backup documentation. The last one catches many teams out: you restore the database, and every link to an uploaded file is broken.

Make a short inventory of everything your app needs to run:

1. The database: tables and their contents.
2. Uploaded files: whatever your users put in storage buckets.
3. Configuration: environment variables, database policies, scheduled jobs, webhooks.
4. Code: usually in Git, but confirm the deployed version matches what is in the repository.
5. Third-party state: payment, email and authentication settings that live in other dashboards.

For each item, write down where its backup is, how often it runs, and how long it is kept. Gaps in this list are your first findings.

How do you run your first restore test?

Do it on a copy, never on your live app. The goal is to rebuild a working version of your app from backups alone and see what is missing.

1. Pick a time and a target. Choose a quiet afternoon. Decide what “working” means: for example, a test user can log in, see their data, open an uploaded file and complete the main action your app exists for.
2. Create an empty, separate project. A new database project and a new hosting environment with a different address. Keeping it separate means a mistake cannot touch production. Our production readiness checklist explains why development and production need to be separate in the first place.
3. Restore the latest database backup into it. Follow your provider’s restore steps exactly. Time it from start to finish.
4. Restore the files. If you have no separate file backup, note that as a finding, because you have just learned you cannot get them back.
5. Point a copy of your app at the restored data. Deploy the same code version as production, with environment variables for the test project. Use new keys for the test project, not your production secrets; see exposed secrets in AI-built apps for why.
6. Check it against your definition of “working”. Log in, click through, open files, run the main action.
7. Check your security rules came back too. If you use Supabase, confirm row level security is still on for every table in the restored copy. Our guide to Supabase row level security shows how.
8. Write down three numbers. How old was the newest data you recovered? How long did the whole restore take? What did you have to fix by hand?
9. Delete the test environment when you are done, so it does not become an unprotected copy of your users’ data.

What should you write down afterwards?

A one-page restore runbook. It should let someone other than you restore the app at 2am. Include:

• where each backup lives and who has access to it,
• the exact steps you followed, including any manual fixes,
• the time each step took,
• the gaps you found and who is fixing them,
• the date of the test and the date of the next one.

Those three numbers from step 8 matter to more than engineers. They tell you, in plain terms, how much data you could lose and how long your customers would wait. If either is unacceptable, you now know what to spend money on: more frequent backups, point-in-time recovery, or a separate file backup.

How often should a small team test?

There is no single right answer, but a simple rhythm works for most small apps:

• After any major change to the database structure, storage or hosting.
• Every quarter as a routine, even if nothing big has changed.
• After a provider changes its plans or backup features. Read their changelog.

Keep at least one copy somewhere your main account cannot delete. CISA’s advice on offline, encrypted copies exists because some attacks look for reachable backups to destroy first (CISA Ransomware Guide). For a small app, a scheduled export to separate storage under a different account is a reasonable start.

Who should run the test?

Ideally, not the person who set up the backups. A restore test is partly a test of your documentation, and the person who built the system will fill gaps from memory without noticing. If you are a solo founder, write the steps down first, then follow only what you wrote. If you have a small team, ask someone else to follow the runbook while you watch and take notes.

Either way, make sure at least two people can reach the backups and the provider dashboards. A backup that only one person can open is a single point of failure, whether that person is on holiday, unwell or has left the company. The same applies to the accounts that hold your domain, your hosting and your payment provider.

What are the common gaps we see?

These turn up often enough that they are worth checking first:

• Backups switched on for the database but not for uploaded files.
• A free plan with no automatic backups at all, and no export routine.
• Only one person able to access the backups.
• Retention too short to catch a problem noticed after a fortnight.
• Restores that work but bring back a database with security rules missing or out of date.
• No record of which code version matched which backup.

Want help keeping it running?

Restore testing is part of our ongoing support, from $249 a month: we run scheduled restore tests, keep the runbook current, and a named engineer approves every change, with every action recorded. If you would like to know where you stand first, start with a free production check: a call, a written report and a quote.

Sources

• CISA, #StopRansomware Guide
• Fortune, Replit AI agent deletes production database (23 Jul 2025)
• Supabase, Database backups

Why does Supabase depend so much on RLS?

Supabase lets your website talk to the database without a server in between. That is why AI app builders such as Lovable use it: it is fast to set up and there is less code to write.

The trade-off is that your website has to carry a key to reach the database, and anything in a website can be read by anyone. Supabase’s answer is that the publishable key is safe to ship because “it only reaches what Row Level Security allows” (Supabase API keys docs). Put the other way round: the public key is only as safe as your RLS rules.

Supabase’s own guidance is to “enable RLS on every table in an exposed schema”, and it warns that without RLS such a table is readable and writable by any role that has been granted access to it (Supabase RLS docs).

What has gone wrong in AI-built apps?

The best-documented case involves Lovable. A researcher, Matt Palmer, found that a Lovable-built site let anyone pull full user records by tweaking database queries. A follow-up scan found 303 endpoints across 170 projects without proper RLS, exposing names, emails, phone numbers, payment status and API keys (Superblocks, 2025). The issue was recorded as CVE-2025-48757, which Lovable disputes on the basis that each customer is responsible for their own app’s data (SentinelOne).

Wider samples point the same way. In a May 2025 sample of 1,645 Lovable-built apps, 170 let anyone access personal information, and the same reporting says about 70% of Lovable apps had RLS disabled entirely (The Next Web, 2026).

The problem is not unique to one tool. Any AI assistant that creates tables quickly, then adds a permissive rule to make an error go away, can produce the same result.

What are the common RLS mistakes?

We see four patterns again and again.

RLS switched off on some tables

The main tables get rules, but a table added later, perhaps for messages, invoices or uploaded documents, does not. Supabase notes that on existing projects, new tables in the public schema start with privileges granted to the anon and authenticated roles, and it points to event triggers as a way to switch RLS on for every new table automatically (Supabase RLS docs).

RLS switched on with a rule that allows everything

A rule such as “allow read where true” turns RLS on in name only. AI tools sometimes write this when a page fails to load. Note that a scanner which only checks whether a policy exists will not catch it: Lovable’s early security scan was criticised because it “only flagged the presence of RLS, not whether it worked” (Superblocks, 2025).

Rules that forget logged-out visitors

A rule that compares the owner of a row with auth.uid() (the ID of the person making the request) looks correct. But for a logged-out visitor, auth.uid() returns null. Supabase recommends writing the check explicitly as auth.uid() IS NOT NULL AND auth.uid() = user_id so the intent is clear (Supabase RLS docs).

The secret key used in the browser

Supabase’s secret key, and the older service_role key, bypass RLS completely. If an AI tool puts it in browser code to “fix” a permissions error, every rule you wrote stops mattering. Supabase says it should never go “in a browser, a shipped application, or source control” (Supabase API keys docs). Our post on exposed secrets in AI-built apps explains how to check for this and what to do if you find it.

How can you test your own RLS?

You can do the first two checks without an engineer. The third needs someone comfortable with the database.

1. Look at the dashboard. In the Supabase dashboard, find where your tables and their policies are listed. Every table that holds user data should show RLS as enabled and list at least one policy. Write down any that do not.
2. Read each policy in plain words. For each table, ask: who can read a row, who can add one, who can change one, who can delete one? If the answer to any of these is “anyone” and the table holds personal data, that is a finding.
3. Test from the outside. Have an engineer call the database API with only the publishable key and no login, then again logged in as test user A trying to read user B’s rows. Both should return nothing that does not belong to the caller. This is the test that matters, because it checks what the rules actually do rather than what they say.

Repeat the third test after every significant change. AI tools can rewrite policies as a side effect of an unrelated request.

Can’t you just ask the AI tool to fix it?

You can ask, and it may help, but treat the answer as a draft. The same habit that created the problem, making an error disappear as quickly as possible, can produce a fix that looks right and is not. A policy that checks the wrong column, or one that lets any logged-in user read every row, will pass a quick click-through and still leak data.

Two rules keep this safe. First, have a person who understands the data model read every policy change before it goes live. Second, re-run the outside-in test from the previous section after each change, because a policy is only correct if it blocks the requests it should. “The tool says RLS is enabled” is not the same as “a stranger cannot read our users’ data”.

What does a good RLS set-up look like?

A sound set-up for a typical app has a few properties:

• RLS is on for every table in the exposed schema, with new tables switched on automatically.
• Each table has separate policies for reading, inserting, updating and deleting, rather than one rule for everything.
• Policies tie rows to the owner, an organisation or a role, and check that the user is logged in.
• The secret key only ever runs on a server or in a server function.
• Someone re-runs the outside-in test whenever the schema changes.

If RLS was off, what else should you do?

Fixing the rules stops future exposure. It does not tell you whether someone already took the data. Check your Supabase logs for unusual reads, rotate any keys that were stored in exposed tables, and take advice on whether you need to notify users. In India, the DPDP Rules 2025 set out breach reporting to the Data Protection Board and to affected people, with those duties phasing in by May 2027 (AMS Shardul, 2025).

It is also a good moment to confirm you can restore your data if it was changed; see our guide to backup and restore testing for small apps. RLS is one item on our production readiness checklist for vibe-coded apps, and the other eleven are worth a look too.

Want us to check it?

Our free production check tests your RLS from the outside, the way an attacker would, and covers secrets, backups, environments and privacy. You get a call, a written report and a quote, and a named engineer approves every fix. More on how we work with AI-built apps.

Sources

• Supabase, Understanding API keys
• Supabase, Row Level Security
• Superblocks, Lovable RLS vulnerability explained
• SentinelOne, CVE-2025-48757 entry
• The Next Web, Lovable vibe-coding security issues (2026)
• AMS Shardul, Enforcement of the DPDP Act and notification of the DPDP Rules

It is written for compliance leads and engineering leads who have to agree on the same record.

Why aren’t ordinary logs enough?

Application logs are built for debugging. They tell an engineer that a request failed at 14:02. An auditor needs something different: evidence of authority. The question we described in Your AI Copilot Can’t Save You From an Audit is “who was in charge when the AI acted?”, and a stack trace cannot answer it.

AI adds two complications. The same input can produce different outputs, so you need to keep what the model actually said, not just what it was asked. And the action is often split across systems: a model proposes, a person approves, a separate service executes. If those three pieces live in three logs with no shared identifier, nobody can join them up later.

What do the rules already require?

Several frameworks already expect logs, even if none of them hands you a schema.

• EU AI Act. Article 12 requires high-risk AI systems to “technically allow for the automatic recording of events” over their lifetime. For certain biometric systems it spells out minimum content, including the period of each use, the input data that led to a match, and the identity of the people who verified the results (Article 12). Providers must keep those logs for at least six months (Article 19), and so must deployers, for the logs under their control (Article 26). Following the Digital Omnibus on AI, most high-risk obligations now apply from 2 December 2027 for stand-alone systems (Hunton, 2026).
• India, CERT-In directions (2022). Covered entities must keep logs of their ICT systems “securely in India for a rolling period of 180 days”, report specified cyber incidents within six hours, and synchronise clocks with the National Informatics Centre or National Physical Laboratory time servers (Linklaters, 2022).
• India, DPDP Rules 2025. Data fiduciaries must retain personal data, associated traffic data and processing logs for at least one year from the date of processing, for the purposes listed in the Rules (AMS Shardul, 2025).
• RBI FREE-AI report (2025). The committee recommended AI incident reporting and audit processes for regulated entities, along with AI inventories and board-approved AI policies (Khaitan & Co, 2025). The recommendations are not binding on their own, but they show where supervisors are looking.

Check which of these apply to you with your counsel. Our AI governance guide for regulated industries covers them in more depth.

The checklist: what should each AI action record?

We group the fields into six stages. One shared action ID should run through all of them.

1. Identity and context

• [ ] Action ID, unique, carried through every system the action touches.
• [ ] Requester: the person or service account that started it, with their role at the time.
• [ ] On whose behalf, if an agent acts for a user or a team.
• [ ] Timestamp from a synchronised clock, in an international format, with time zone.
• [ ] Application and version: which product, environment and release.

The OWASP Logging Cheat Sheet frames this as being able to answer “when, where, who and what” for every event (OWASP).

2. The model call

• [ ] Model provider, model name and version.
• [ ] Prompt or template version, and a reference to the exact input (or a hash of it, if the input holds personal data).
• [ ] Data sources retrieved: which documents or records the AI was given.
• [ ] The model’s output, as returned, before any post-processing.
• [ ] The proposed action, in structured form: “update record X, field Y, from A to B”.

3. The policy check

• [ ] Policy and rule version evaluated.
• [ ] Result: allowed, denied, or needs approval.
• [ ] Reason: which rule triggered.
• [ ] What happened on error. If the check failed or timed out, the record should show that the action stopped. That fail-closed behaviour is part of what we mean by non-bypassable governance.

4. Human approval

• [ ] Named approver, not a shared account or “admin”.
• [ ] What they were shown when they approved: the proposal, the evidence, the policy result.
• [ ] Decision and time: approved, rejected, edited, or timed out (a timeout should count as a rejection).
• [ ] Edits the approver made to the AI’s proposal.

The EU AI Act asks deployers to assign oversight to people “who have the necessary competence, training and authority” (Article 26). The approval record is how you show you did.

5. Execution and outcome

• [ ] What actually ran, which may differ from what was proposed.
• [ ] Before and after state of anything changed, or a reference to it.
• [ ] Result: success, partial, failed, rolled back.
• [ ] Downstream effects: messages sent, payments triggered, records shared.

6. Integrity and access

• [ ] Tamper evidence: each record linked to the previous one, for example in a hash chain, so edits or deletions are detectable.
• [ ] Write-once storage, or a copy moved to read-only storage quickly.
• [ ] Access log for the audit trail itself: who read it and when.
• [ ] Retention period set to the longest rule that applies to you.

OWASP recommends tamper detection, copying logs to read-only media “as soon as possible”, and monitoring both access to logs and signs that logging has stopped (OWASP).

What should you not log?

An audit trail that leaks data creates a new risk. OWASP lists data that should not be written directly to logs, including session identifiers, access tokens, passwords, encryption keys, database connection strings, sensitive personal data and payment card data. Where you need them, mask, hash or encrypt them first (OWASP).

For AI specifically, decide up front whether full prompts and outputs go in the trail or in a separate, more tightly controlled store referenced by ID. Prompts often contain whatever personal data the user typed. The DPDP retention duty above applies to processing logs too, so the trail is itself personal data to be governed.

How do you test an audit trail?

Pick a real AI-assisted action from last week and ask someone outside the team to reconstruct it using only the trail. They should be able to answer, in writing and within an hour:

1. Who started it, and with what authority?
2. What did the AI see, and what did it propose?
3. Which rule applied, and what did it decide?
4. Who approved it, and what were they shown?
5. What changed, and can it be undone?

Any question they cannot answer is a missing field. Repeat the exercise each quarter, and after any change to models, policies or approval flows.

How we approach it

Every QUAICU delivery writes to an append-only, hash-chained ledger with a named approver for consequential actions. The full model is on our trust page, and our page for regulated teams explains how it fits sectors that answer to a regulator. If you want to test your current trail against this checklist, talk to us.

Sources

• EU AI Act, Article 12: Record-keeping
• EU AI Act, Article 19: Automatically generated logs
• EU AI Act, Article 26: Obligations of deployers
• Hunton Andrews Kurth, EU Digital Omnibus on AI enters into force (2026)
• Linklaters, India’s CERT-In cyber security directions (2022)
• AMS Shardul, Enforcement of the DPDP Act and notification of the DPDP Rules
• Khaitan & Co, ERGO on the RBI FREE-AI framework (Aug 2025)
• OWASP Logging Cheat Sheet

What counts as a “secret” in a small app?

A secret is any value that lets its holder act as your app rather than as a visitor. Typical examples are payment provider secret keys, database admin keys, email and SMS service keys, AI model API keys, and database connection strings.

Not every key is a secret. Many services issue two kinds: a public key designed to sit in the browser and a secret key that must stay on a server. Supabase is a good example. Its publishable key is safe in shipped code because “it only reaches what Row Level Security allows”, while a secret key “bypasses every Row Level Security policy you have” and should never be put “in a browser, a shipped application, or source control” (Supabase API keys docs). The public key is only safe if your database rules are right, which we cover in Supabase row level security for AI-built apps.

How do secrets end up in the browser?

Most modern web frameworks let you mark a setting as safe for the browser by giving it a prefix. Vite exposes any variable starting with VITE_ “in client-side source code after Vite bundling” and warns that these “should not contain sensitive information such as API keys” (Vite docs). Next.js does the same for variables starting with NEXT_PUBLIC_, which it inlines “into any JavaScript sent to the browser” (Next.js docs).

When an AI assistant hits an error like “variable is undefined in the browser”, a common fix is to add that prefix. The error goes away and the secret is now shipped to every visitor. Nothing breaks, so nobody notices.

The other common path is the code itself. Ask an AI tool to “connect to Stripe” and it may paste the key directly into a file. That file is then committed, pushed and sometimes shared.

How big is the problem?

Large. GitGuardian counted 23.8 million secrets leaked on public GitHub repositories in 2024, a 25% increase on the year before. It also found that 70% of secrets leaked in 2022 were still active, and that 35% of the private repositories it examined contained secrets (GitGuardian, 2025). A private repository is not a safe place for a key; it only narrows who can find it.

In AI-built apps specifically, a security researcher’s scan of Lovable-built sites found 303 endpoints across 170 projects without proper row level security, and the exposed data included API keys for services such as Gemini and Google Maps alongside user records (Superblocks, 2025). The issue was later recorded as CVE-2025-48757; Lovable disputes the CVE on the grounds that each customer is responsible for protecting their own app’s data.

How can you check your own app in 20 minutes?

You can do most of this without writing code.

1. Read your live site’s source. Open your app, right-click, choose “View page source”, then open your browser’s developer tools and look at the loaded JavaScript files. Search for secret, sk_live, sk_test, service_role, password, api_key and token. Note anything that looks like a long random string next to one of those words.
2. List your environment variables. In your hosting dashboard, list every variable. Any with a VITE_, NEXT_PUBLIC_, PUBLIC_ or EXPO_PUBLIC_ prefix is visible to visitors. Check each one against the provider’s documentation: is it the public key or the secret one?
3. Search your repository history, not just today’s files. A key removed last month is still in old commits. A secret scanner such as GitGuardian’s tools or Yelp’s detect-secrets, which the OWASP guidance names as a mature option (OWASP Secrets Management Cheat Sheet), will scan the whole history.
4. Check where the code has been shared. Forks, zip files sent to contractors, screenshots in support tickets, pasted snippets in chat tools. If a key went there, treat it as exposed.

You found an exposed key. What now?

Revoke first, investigate second. The OWASP guidance is blunt: keys that were exposed “should undergo immediate revocation” (OWASP). Work through the steps in this order:

1. Create a new key and revoke the old one in the provider’s dashboard. Deleting the key from your code does nothing to a copy someone already has. Supabase notes that an attacker can “still use the key from other tools” even if the browser blocks it (Supabase).
2. Put the new key somewhere only your server can read: your host’s encrypted environment settings or a secrets manager, without a public prefix.
3. Move any browser code that used the secret behind a small server function. The browser asks your server; your server holds the key and calls the provider.
4. Check the provider’s logs for use you do not recognise: unexpected charges, emails, AI usage or database reads. Note the dates.
5. Clean up the old key from code and, if needed, from repository history. This matters less than revocation, because a revoked key is useless.
6. Decide whether personal data was exposed. If the key gave access to user data, you may have obligations to report. In India, the DPDP Rules 2025 require a breach report to the Data Protection Board and notice to affected people, with those duties phasing in by May 2027 (AMS Shardul, 2025). Take advice early.

How do you stop it happening again?

Prevention is mostly habit and a couple of free tools.

• Turn on push protection. GitHub’s push protection blocks pushes that contain recognisable credentials. For users it is on by default for public repositories, but protection at the repository level is off by default and must be enabled by an owner (GitHub docs).
• Add a pre-commit scanner so secrets are caught on the laptop, before they reach any repository.
• Give your AI tool a standing rule: “Never put secret keys in client code or in any variable with a public prefix. Ask me where secrets should live.” It will not always follow it, which is why review still matters.
• Use the narrowest key that works. Many providers let you create restricted keys that can only do one thing. A leaked restricted key does less damage.
• Rotate on a schedule, so a key that leaks quietly stops working on its own (OWASP).

Secrets are one item on a longer list. Our production readiness checklist for vibe-coded apps covers the other eleven, and our guide to backup and restore testing covers what to do if a leaked key was used to damage data.

Want a second pair of eyes?

Our free production check includes a search for exposed secrets in your live site and code history, along with security, backups, environments and privacy. You get a call, a written report and a quote. See how we help teams with AI-built apps.

Sources

• Supabase, Understanding API keys
• Vite, Env variables and modes
• Next.js, Environment variables guide
• GitGuardian, The State of Secrets Sprawl 2025
• Superblocks, Lovable RLS vulnerability explained
• SentinelOne, CVE-2025-48757 entry
• OWASP Secrets Management Cheat Sheet
• GitHub, About push protection
• AMS Shardul, Enforcement of the DPDP Act and notification of the DPDP Rules

This guide is for compliance, risk and engineering leads at banks, NBFCs, insurers, hospitals, universities and other institutions that answer to a supervisor. It covers the rules that apply in India and the EU, the building blocks of a working governance set-up, how to tell real governance from the appearance of it, and a 90-day plan to get started. It is not legal advice; check how each instrument applies to you with counsel.

Why is AI governance different in a regulated industry?

In most businesses, an AI mistake is a product problem. In a regulated institution it is also a compliance event, because the decision touches a customer’s money, health, education record or personal data, and someone will later be asked to justify it.

That changes the question. A product team asks “does the AI work?” A regulator asks “who was in charge when it acted, under what rule, and can you prove it?” We made that argument in Your AI Copilot Can’t Save You From an Audit. Governance is the answer to the second question, built before you need it.

Adoption is still early in many regulated sectors, which is the right time to get this right. When the Reserve Bank of India surveyed regulated entities and fintechs for its FREE-AI committee, 20.8% were deploying AI systems, mainly in customer support, sales, credit underwriting and cybersecurity, while 67% said they were interested in exploring AI use cases (Khaitan & Co, 2025). The gap between those two numbers is where most governance decisions will be made over the next two years.

Which rules apply to AI in regulated industries?

There is no single AI law in India. Instead, a regulated institution sits under several overlapping instruments, and EU rules reach Indian organisations that serve EU markets. The summaries below are deliberately general.

India: Digital Personal Data Protection Act, 2023 and DPDP Rules, 2025

The DPDP Act governs how personal data is processed, whether by people or by AI. MeitY notified the DPDP Rules in November 2025 with a staggered start: some provisions immediately, Consent Manager registration after 12 months, and the main operational duties, including notice and consent, security safeguards, breach reporting and data principal rights, from 14 May 2027 (AMS Shardul, 2025).

Two points matter most for AI. First, the Rules require data fiduciaries to retain personal data, associated traffic data and processing logs for at least one year from the date of processing, for specified purposes (AMS Shardul, 2025). AI processing logs are processing logs. Second, the penalties are significant: the Act’s Schedule sets a ceiling of up to ₹250 crore for failing to take reasonable security safeguards, up to ₹200 crore for failing to notify a breach, and up to ₹200 crore for breaching duties on children’s data (King Stubb & Kasiva). These are maximums set by the Data Protection Board case by case, not automatic fines.

India: CERT-In cyber security directions, 2022

CERT-In’s April 2022 directions require covered entities to report specified cyber incidents within six hours of noticing them, keep ICT system logs securely in India for a rolling 180 days, and synchronise clocks to National Informatics Centre or National Physical Laboratory time servers. They took effect on 27 June 2022 (Linklaters, 2022). An AI system that acts on your infrastructure produces exactly the kind of logs these directions cover, and an AI-related incident is still an incident.

India: RBI’s FREE-AI framework for the financial sector

In August 2025 the RBI published the report of its committee on a Framework for Responsible and Ethical Enablement of Artificial Intelligence (FREE-AI) in the financial sector, setting out 7 Sutras as foundational principles and 26 recommendations under six pillars (RBI press release, 2025). The pillars are Infrastructure, Policy, Capacity, Governance, Protection and Assurance (KPMG, 2025).

The recommendations most relevant to governance teams include board-approved AI policies covering governance, lifecycle management, risk controls and third-party vendor liabilities; AI inventories covering models, use cases, dependencies and risks; AI incident reporting and audit processes; and AI-related disclosures in annual reports (Khaitan & Co, 2025). A committee report is not a direction, but regulated entities would be unwise to treat it as optional reading.

EU: the AI Act, as amended by the Digital Omnibus

The EU AI Act applies to providers and deployers whose AI systems are placed on the EU market or whose outputs are used in the EU, which can include Indian institutions and their vendors. In July 2026 the Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force and moved the high-risk obligations: to 2 December 2027 for stand-alone high-risk systems listed in Annex III (which include areas such as employment and education) and to 2 August 2028 for AI embedded in regulated products (Hunton Andrews Kurth, 2026). The delay changes timing, not substance.

For high-risk systems, the Act requires automatic logging over the system’s lifetime (Article 12), log retention of at least six months by both providers and deployers (Article 19; Article 26), and human oversight assigned to people “who have the necessary competence, training and authority” (Article 26). Fines reach up to €35 million or 7% of worldwide annual turnover for prohibited practices, and up to €15 million or 3% for breaches of most other obligations, whichever is higher, with lower caps for SMEs (Article 99).

ISO/IEC 42001:2023, the AI management system standard

ISO/IEC 42001, published on 18 December 2023, “specifies the requirements and provides guidance for establishing, implementing, maintaining and continually improving” an AI management system, and is intended for any organisation that provides or uses AI-based products or services (Standards Norway listing). It is voluntary, but it gives you a recognised structure for policy, roles, risk assessment and continual improvement, and it is a useful common language with auditors and enterprise customers.

What does a working AI governance set-up include?

Whatever mix of rules applies to you, the same building blocks keep coming up. We think of them as eight controls. Each one should produce evidence, not just intent.

1. An AI inventory

You cannot govern what you have not listed. Record every AI system in use, including vendor tools and copilots: what it does, which data it touches, who owns it, which model and version it uses, and what it is allowed to change. The FREE-AI recommendations on AI inventories cover models, use cases, dependencies and risks (Khaitan & Co, 2025), which is a good minimum.

2. Risk classification

Not every use needs the same controls. A model that drafts internal meeting notes is not a model that recommends a credit limit. Classify each inventory entry by the consequence of a wrong output for a customer, patient or student, and by whether it can act on its own. Higher classes get stricter controls below.

3. A board-approved AI policy

The policy states what AI may be used for, who decides, what is prohibited, and how exceptions are handled. In financial services the FREE-AI report expects it to be board-approved and to cover governance, lifecycle management, risk controls and vendor liabilities. Elsewhere, board approval is still the simplest way to show that accountability sits at the top.

4. Enforcement outside the model

This is where many set-ups fall short. Rules written in a prompt, or switched on in a vendor’s settings page, can be bypassed by a bug, a clever input or a rushed administrator. Real governance evaluates the rule in a separate layer before the AI is allowed to act, and stops the action if the check fails or errors. We set out what that requires, and six questions to test any vendor, in Non-Bypassable AI Governance: What It Means and How to Test It.

5. Human oversight with named approvers

For consequential actions, a named person with the competence and authority to say no should approve before the action runs. “The system approved it” is not an answer an auditor will accept. A timeout should count as a rejection. The approver should see the AI’s proposal, the evidence behind it and the policy result, and their decision should be recorded.

6. An audit trail that can be replayed

Every AI-assisted action should leave a record that lets an outsider reconstruct it: who asked, what the AI saw and proposed, which rule applied, who approved, what changed. The record should be tamper-evident and kept for the longest retention period that applies. Our AI audit trail checklist lists the fields stage by stage and maps them to the EU AI Act, DPDP and CERT-In.

7. Data residency and vendor control

Know where every piece of data the AI touches is stored and processed, which model providers see it, and under what contract. For institutions holding student records, patient files or core banking data, that often rules out sending data to general-purpose public AI services. We have written about why in The 2026 AI Data Crisis: Why Public Clouds Are Failing Regulated Institutions and, from a national perspective, in Governance Is the New Product Category. Here Is Why India Cannot Borrow It.

8. Incident response and testing

Decide in advance what counts as an AI incident (a wrong decision at scale, a data exposure, a model acting outside its policy), who is told, and how fast. Align it with existing duties such as CERT-In’s six-hour window and DPDP breach reporting. Then test: run a tabletop exercise, try to bypass your own controls, and reconstruct a real action from the audit trail.

How should governance handle AI agents?

Agents raise the stakes because they do not just suggest; they act. An agent that can read a ticket, query a customer record, draft a reply and send it has crossed from advice into execution, and every step it takes is a potential compliance event.

The building blocks still apply, with three additions:

• Scoped, revocable authority. Give each agent the narrowest permissions that let it do its job, for a limited time, and make them easy to withdraw. Log any attempt to go beyond them.
• Declared actions. List the actions an agent may take, and the states a record may move between, in advance. Anything not on the list is refused rather than attempted.
• Approval at the point of consequence. An agent can gather information and prepare a proposal on its own. The step that changes a customer’s position, sends money or shares data should wait for a named person.

The test is the same as for any other AI system: can you reconstruct what the agent did, step by step, and show who authorised the steps that mattered?

What should you ask AI vendors?

Most regulated institutions will buy at least some of their AI. Contracts and due diligence questionnaires should cover governance, not just security. At a minimum, ask each vendor:

1. Which model providers see our data, where is it processed, and is it used for training?
2. Where do the rules that constrain the AI live, and can your staff or ours switch them off?
3. What happens when a policy check fails or times out?
4. Can we export a complete, tamper-evident record of every AI action on our data, and in what format?
5. How quickly will you tell us about an AI incident, and does that fit our CERT-In and DPDP timelines?
6. Who at your company can access our environment, and is their access logged in the same record?

Write the answers into the AI inventory entry for that system, and revisit them when the vendor changes models or providers.

How can you tell real governance from governance theatre?

Many AI products now describe themselves as governed. The test is whether each control produces evidence and whether it can be switched off.

Signs of real governance:

• The rules live outside the model and are versioned.
• A failed or errored check stops the action.
• Consequential actions have a named approver, visible in the record.
• You can replay what happened on a given day from the audit trail alone.
• Administrators and vendor staff pass through the same gate as everyone else, and their changes are logged.

Signs of theatre:

• Governance is a PDF, a training deck or a vendor’s “responsible AI” page.
• Controls are toggles an administrator can turn off without a trace.
• Logs exist but cannot be joined across the model, the approval and the system that acted.
• Nobody outside the vendor can say where the data went.

If you are assessing a vendor, ask for a live demonstration of a denied action, a timed-out approval and a replayed audit record. A vendor with a real design can show all three in one meeting.

How does this look in different sectors?

The building blocks are the same, but the emphasis shifts.

Banks, NBFCs and insurers. Expect supervisors to look for the FREE-AI themes: board-approved policy, inventory, incident reporting and audit. Credit, fraud and claims decisions are the obvious high-consequence uses. Third-party AI vendors need the same scrutiny as any outsourced critical service.

Hospitals and health providers. Patient data is personal data under the DPDP Act, and an AI suggestion that reaches a clinical decision needs a clinician as the named approver. Data residency questions are usually decisive.

Universities and schools. Admissions, assessment and student support involve personal data, often including minors, which carries the higher DPDP penalty band for children’s data. Where EU students or programmes are involved, education is one of the areas the EU AI Act treats as high-risk.

Public sector and critical infrastructure. CERT-In duties, data localisation expectations and public accountability usually push towards self-hosted or sovereign deployments with strict logging.

In every sector the core question is the same: for each AI action that matters, can you show who was in charge?

What does a 90-day starting plan look like?

You do not need a finished programme to make real progress. This sequence works for most mid-sized institutions.

Days 1 to 30: see what you have

• Build the AI inventory, including shadow use of public tools.
• Classify each entry by consequence and autonomy.
• Map which rules apply to each: DPDP, CERT-In, sector regulator, EU AI Act.
• Name an accountable owner for each high-consequence use.
• Draft the AI policy for board review.

Days 31 to 60: put controls on the highest-risk uses

• For the top three high-consequence uses, move rule checks outside the model and make them fail closed.
• Introduce named human approval for consequential actions.
• Start writing a joined-up audit trail with a shared action ID, using the audit trail checklist.
• Confirm where each system’s data is stored and processed, and close any gaps in vendor contracts.

Days 61 to 90: prove it works

• Have someone outside the team reconstruct three real AI actions from the audit trail.
• Run a tabletop AI incident exercise against your CERT-In and DPDP timelines.
• Try to bypass your own controls: as an administrator, as a vendor, with a malformed request.
• Take the policy and results to the board, with a plan for the remaining inventory.

What are the most common mistakes?

• Starting with a policy and stopping there. A policy without enforcement and evidence will not satisfy an auditor.
• Trusting model-level safety settings as controls. They help, but they sit inside the system they are meant to constrain.
• Logging everything except the approval. The approval is the part the regulator cares about most.
• Forgetting vendor and administrator paths. Integrators and privileged users should face the same gate as everyone else.
• Treating the EU delay as a reason to wait. The obligations did not change, and India’s DPDP operational duties start in May 2027.
• Over-collecting in logs. Prompts and outputs can contain personal data; the audit trail must be governed too.

Frequently asked questions

Is there an AI-specific law in India?

Not a single one. AI in a regulated Indian institution is governed through existing instruments, chiefly the DPDP Act and Rules, CERT-In’s directions and sector regulators’ guidance such as the RBI’s FREE-AI report. Check with counsel for your sector.

Does the EU AI Act apply to an Indian company?

It can, if your AI systems are placed on the EU market or their outputs are used in the EU. Get advice on your specific position, especially for education, employment and financial uses.

Do we need ISO/IEC 42001 certification?

It is voluntary. Many organisations use it as a framework without certifying; others certify because enterprise customers or partners ask for it. Either way, its structure maps well onto the eight controls above.

Can we use public AI tools at all?

Often yes, for low-consequence tasks that do not involve regulated data. For anything touching customer, patient or student records, check data residency, contracts and logging before use, and record the decision in your inventory.

Who should own AI governance?

Accountability should sit with a named senior owner and the board, with compliance, risk and engineering sharing the work. The worst outcome is governance owned by nobody because it sits between teams.

How QUAICU approaches it

Every QUAICU delivery runs on one enforcement model: policy checked before the AI acts, a named engineer approving every change, fail-closed behaviour, and an append-only, hash-chained ledger of every action. The full model is on our trust page, and our page for regulated teams explains how we work with institutions that answer to a regulator. If you want to test your current set-up against this guide, talk to us.

Sources

• Khaitan & Co, ERGO on the RBI FREE-AI framework (Aug 2025)
• RBI, press release on the FREE-AI committee report (13 Aug 2025)
• KPMG India, RBI FREE-AI committee report
• AMS Shardul, Enforcement of the DPDP Act and notification of the DPDP Rules
• King Stubb & Kasiva, Penalties and adjudication under India’s DPDP Act 2023
• Linklaters, India’s CERT-In cyber security directions (2022)
• Hunton Andrews Kurth, EU Digital Omnibus on AI enters into force (2026)
• EU AI Act, Article 12: Record-keeping
• EU AI Act, Article 19: Automatically generated logs
• EU AI Act, Article 26: Obligations of deployers
• EU AI Act, Article 99: Penalties
• Standards Norway, ISO/IEC 42001:2023 listing

You do not need to be an engineer to run most of it. Where a check needs one, we say so.

Why does AI-built code need a separate check?

AI coding tools are very good at making things work and much less reliable at making them safe. When Veracode asked more than 100 language models to complete 80 coding tasks, 45% of the test cases introduced a vulnerability from the OWASP Top 10 list of common web security flaws (Veracode, 2025). Those were curated tasks, not production apps, but the direction is clear.

A separate review of 470 open-source pull requests by CodeRabbit found AI-written changes averaged 10.83 issues each, against 6.45 for human-written ones, roughly 1.7 times as many (The Register, 2025).

None of this means you should stop using the tools. It means someone has to check what they produce before customers rely on it. That is the gap we describe on our AI-built apps page.

Security: who can see what?

1. Can a logged-out stranger read your data?

Open your app in a private browser window, without logging in, and try the pages and links your users see. Then ask an engineer to call your database API directly with the public key that ships in your website. If anything comes back that belongs to a user, you have a problem.

This is the most common serious flaw we see in AI-built apps, and it is not hypothetical. In a May 2025 sample of 1,645 Lovable-built apps, 170 let anyone access personal information (The Next Web, 2026). If your app uses Supabase, read our guide to Supabase row level security in AI-built apps.

2. Can one logged-in user read another user’s data?

Create two test accounts. Log in as the first, note the address of a page that shows that user’s own record, then log in as the second and paste the same address. Try changing any ID you can see in the address bar. A safe app refuses. An unsafe one shows you someone else’s invoice, profile or messages.

3. Are any secret keys visible in the browser?

Open your live site, right-click, choose “View page source”, and search for words like secret, sk_, service_role and api_key. Anything that lets someone charge cards, send email or bypass your database rules must never be there. Tools such as Vite and Next.js deliberately bundle variables with certain prefixes into the code sent to every visitor, which is how many keys leak (Vite docs; Next.js docs). Our post on exposed secrets in AI-built apps walks through what to look for and what to do if you find one.

4. Are secrets kept out of your code history?

A key deleted from today’s code can still sit in an old commit. GitGuardian counted 23.8 million secrets leaked on public GitHub in 2024, and found that 70% of secrets leaked in 2022 were still active (GitGuardian, 2025). If a key was ever committed, assume it is known and rotate it.

Data: what happens when something goes wrong?

5. Do you have backups, and have you restored one?

Check what your hosting plan actually backs up. On Supabase, for example, daily backups are automatic on paid plans, while free-plan projects are told to export their data themselves, and database backups do not include files stored through the Storage API (Supabase docs). A backup you have never restored is a hope, not a plan. Our guide to backup and restore testing for small apps shows how to run a first test in an afternoon.

6. Are development and production separate?

If you test new features against the same database your customers use, one bad instruction can wipe it. In July 2025 a Replit AI agent deleted a live production database during a declared code freeze, and Replit then announced automatic separation of development and production databases (Fortune, 2025). Make sure your AI tool, and anyone experimenting, works on a copy.

7. Do you know what personal data you hold?

Write a one-page list: what personal data you collect, where it is stored, who can see it, and how long you keep it. If you serve users in India, the Digital Personal Data Protection Act and its 2025 Rules bring duties on notice, security safeguards and breach reporting, with most operational duties starting in May 2027 (AMS Shardul, 2025). You cannot meet them without knowing what you hold.

Operations: can you see and undo changes?

8. Does someone review changes before they go live?

AI tools can change dozens of files in one go. Somebody who understands the code should read each change before it reaches users, with special attention to anything touching login, payments or data access. “It worked when I clicked through it” is not a review.

9. Can you roll back a bad release in minutes?

Find out now how you would return to yesterday’s version if today’s breaks checkout. On most platforms this is a button or a single command. Write it down and try it once while nothing is on fire.

10. Will you know when the app is down or throwing errors?

Set up a free uptime monitor that checks your main page every few minutes and alerts you by email or chat. Add error tracking so you hear about crashes from a dashboard rather than from an angry customer.

11. Are payments and webhooks verified?

If you take payments, your server should confirm each payment with the payment provider and check the signature on incoming webhooks. An app that trusts whatever the browser says about a payment can be tricked into granting paid access for free.

12. Is there a record of who changed what?

Keep your code in version control, use separate accounts rather than one shared login, and turn on the audit logs your hosting and database providers offer. When something goes wrong, the first question is always “what changed?” You want an answer in minutes.

How do you prioritise if you can’t do all twelve this week?

Start with checks 1, 2 and 3. They cover the failures that expose other people’s data, which is the kind of mistake that is hardest to recover from. Then do 5 and 6, because they decide whether a bad day is an inconvenience or the end of the product. The rest can follow over the next few weeks.

If you find a problem, do not panic and do not ask the AI tool to “fix security” in one prompt. Make a list, fix the most serious item first, and have someone check each fix.

Where to get help

If you would rather have specialists run this for you, our free production check covers security, backups and environments, code and maintainability, and privacy. You get a walkthrough call, a written report and a quote, and a named engineer reviews every change we make after that. Learn more about how we work with AI-built apps.

Sources

• Veracode, AI-generated code security research press release (2025)
• The Register, CodeRabbit analysis of AI-written pull requests (17 Dec 2025)
• The Next Web, Lovable vibe-coding security issues (2026)
• Vite, Env variables and modes
• Next.js, Environment variables guide
• GitGuardian, The State of Secrets Sprawl 2025
• Supabase, Database backups
• Fortune, Replit AI agent deletes production database (23 Jul 2025)
• AMS Shardul, Enforcement of the DPDP Act and notification of the DPDP Rules

It is compatible with games that read keyboard keys. One of them:

• Sansad Showdown, by Shivam (@shivmbuilds). A remarkable game. I highly recommend it.

The mapping window is the whole app: one profile, saved next to the app, and nothing else to install on Windows.

Download

GitHub repository: ramavathdeepak05/PS-Xbox-Controller-adapter

Windows. Double-click GamepadAdapter.exe and the mapping window opens. Nothing else needs to be installed.

Mac (Apple Silicon). Unzip GamepadAdapter-mac.zip and open GamepadAdapter.app. macOS ships the app as a zip because an .app is a folder, and this build is not signed. The first time, right-click GamepadAdapter.app, choose Open, then choose Open again.

macOS will not type keys until Gamepad Adapter is allowed under System Settings → Privacy & Security → Accessibility. Turn the switch on, quit the app, and open it again.

Intel Macs can run the Python source from the repository instead of this app. The same Accessibility permission is required.

Map a button

1. Click the key chip next to a control.
2. Press a key, or hold Ctrl, Alt, or Shift and then press a key. For example, hold Ctrl and press C to bind Ctrl+C. On a Mac, hold Command and then a letter to bind a shortcut such as Cmd+C. Control is still the Control key.
3. Click Apply Changes.

Press only Ctrl, Alt, or Shift, then release it, to bind that modifier by itself. Click the × on a chip to clear it. Until you click Apply Changes, the window shows Not saved yet.

Pause keeps the window open but stops sending keys. Resume turns sending back on. Reset to Default restores the original keys. Clear All empties every binding.

Only one profile is stored, as controller_mapping.json. On Windows it sits next to GamepadAdapter.exe. On a Mac it is saved next to the app, or next to ps3_adapter.py when you run the source. Closing the window closes the app.

Which controller you see

The mapping window puts the connected controller in the middle, with a key chip on every control.

A PlayStation controller shows the PlayStation image, with Share, Options, the touchpad, and the PlayStation button. An Xbox controller shows the Xbox image. The labels switch to View, Menu, LB, RB, LT, RT, and A, B, X, Y. The D-pad and left stick trade places, matching an Xbox pad.

A third-party controller is supported the same way. The picture follows the name Windows or macOS reports. An Xbox name, or an XInput controller, uses the Xbox picture. A name that mentions PlayStation, DualSense, DualShock, or Sony uses the PlayStation picture. Every other USB gamepad uses the PlayStation layout, and you map its buttons from there.

What it is doing

About once a millisecond, the app checks which controls are held. For each one, it looks up the saved binding and holds those keys down. A binding of CTRL+C holds Ctrl, then C. A binding of CMD+C holds Command, then C, which is copy on a Mac. Keys that no held control still needs are released, with the main key released before the modifier.

On Windows, Xbox controllers are read through XInput. PlayStation controllers and other third-party USB gamepads are read through the Windows joystick interface. Keystrokes are sent with SendInput. On a Mac, PlayStation, Xbox, and other USB gamepads are read through SDL, and keystrokes are sent with Quartz, which is why the Accessibility permission is required.

Source

The application and its source are free under the MIT License. The repository is ramavathdeepak05/PS-Xbox-Controller-adapter. It includes ps3_adapter.py, the Mac and Windows backends, the mapping window, and the controller images.

On Windows, from the source:

pip install pywebview pyinstaller
run_adapter.bat

build_app.bat builds a new dist\GamepadAdapter.exe.

On a Mac:

python3 -m pip install --user pywebview pygame
python3 ps3_adapter.py

run_adapter.command does those two steps. The Mac app on the download link above is the Apple Silicon build produced by GitHub Actions.

QUAICU builds and looks after software for businesses. If you have an app that needs to hold up in production, start with a free production check, or see how we work.

Jev, a model from TypeSafe AI, is built for exactly that kind of decision. This guide covers what it is, where it pays off, how to roll it out at enterprise scale, and what others have measured with this kind of system. We implement Jev for client teams, and you can read more about that on our Jev implementation page.

What Jev is, and what it is not

Jev reads text and answers structured questions about it. According to TypeSafe’s documentation, each call takes the content to evaluate and a list of questions, and answers them together in one pass. There are three kinds of question:

• Yes or no, returned as a probability between 0 and 1.
• Choice, returning the selected option with a probability for every option.
• Score, placing the text on a scale of 2 to 10 ordered levels.

It does not write. TypeSafe is explicit that Jev cannot produce prose or code or hold a conversation. Its published price is $0.042 per million input tokens with no charge for output, because the output is a handful of probabilities rather than paragraphs of text. It entered early access on 15 September 2026, and it is also listed on Cloudflare’s model catalogue.

TypeSafe also documents known weaknesses: it is not reliable at counting or exact numbers, its accuracy drops when unrelated material is included in the input, and score levels should not be treated as exact distances. A good implementation is designed around those limits rather than surprised by them.

The best uses

1. Support ticket classification and routing

This is the most direct fit. Each incoming ticket gets a category, a product, an urgency level and a language, and is routed to the right queue. TypeSafe’s own guide to building with Jev uses this example, with tickets below a confidence of 0.8 sent to a person.

Automated ticket routing is well studied. Microsoft’s DeepTriage, a peer-reviewed system for routing Azure incidents to the right team, reached 82.9% F1 and has run in production since 2017. Accenture reports that automated classification in ServiceNow assigns about 2,000 of its roughly 10,000 daily internal IT incidents without a person. Those systems used other models, but the problem and the measurement are the same.

2. AI cost control through routing

If you already use large language models, the cheapest call is the one you don’t make. A fast classifier in front of your models can decide which requests a small model can handle and which need a stronger one. Research on this pattern is encouraging: the RouteLLM team reported cutting costs by over 85% on one benchmark while keeping about 95% of GPT-4’s quality, and the FrugalGPT paper reported savings of up to 98% on its benchmarks. Treat those as best cases from research settings, not promises.

TypeSafe publishes a cascade example in which a small model extracts fields, Jev checks each field, and an expensive model is called only when Jev thinks a field is likely wrong.

3. Escalation to a person

In customer chat, the expensive mistake is keeping someone with a bot when they needed a human. A yes-or-no question such as “does this conversation need a person now?” with a threshold you control is a simple, auditable escalation rule.

4. Guardrails and moderation

Screen user input and AI output against your policies and record a probability for every decision. TypeSafe’s guardrails cookbook maps hazard probabilities to pass, review, block or support. Because each decision is a number, you can show an auditor exactly where the line was drawn.

5. Privacy and DPDP data mapping

India’s DPDP duties for most businesses start in May 2027, and the first step in every compliance guide is knowing where personal data lives. Classifying records, documents and messages by whether they contain personal data is a practical first pass. It should be backed by a person reviewing anything uncertain. No automated scan finds everything.

6. Inbox and alert triage

Shared inboxes and operations alerts are full of noise. Separating real requests from the rest, and grouping duplicates, frees people for the work that matters. In IT operations, PagerDuty’s customer IG Group reported an average 58% reduction in alert noise using this kind of grouping.

How to implement it at enterprise level

The model is the easy part. What makes a classifier safe to rely on is the process around it.

1. Agree the labels. Write down every category with a definition and real examples, agreed with the team that will live with the results. Decide what a wrong answer costs in each category. Misrouting a billing question is cheap; missing a security incident is not.

2. Build a test set. Label a sample of real, recent tickets or messages as your reference. This is the yardstick for everything that follows.

3. Measure per category, not on average. Report precision and recall for every category and look at the confusion matrix. A system that is 92% accurate overall can still be poor on the rare categories that matter most.

4. Run in shadow mode first. Let the classifier run alongside your current process without acting on its answers, and compare. Only switch it on when the numbers hold up on live traffic.

5. Set confidence thresholds with a person behind them. Apply high-confidence results automatically and send the rest to a person. Set thresholds per category, and watch the size of the review queue. If too much lands there, the labels or thresholds need work. Under data-protection law, a person reviewing a significant decision must make a real judgment, not just approve it.

6. Connect your tools. Helpdesks such as Zendesk, Freshdesk, Jira Service Management and ServiceNow can send a webhook when a ticket arrives and accept tags, fields or an assignment back through their APIs. Jev is also available through AI gateways such as Cloudflare AI Gateway, Vercel and LiteLLM.

7. Log and monitor. Record every decision with its probabilities and the input it was based on. Recheck accuracy on fresh samples regularly, and update the labels when your products, customers or language change.

8. Agree the data route. Decide what text is sent, how personal data is minimised first, and which route the data takes. TypeSafe’s privacy policy says it does not train models on customer inputs; zero data retention is offered to enterprise customers, and Cloudflare lists Jev with zero data retention.

A quick cost example

Using TypeSafe’s published price of $0.042 per million input tokens, 10,000 tickets of about 500 tokens each come to 5 million input tokens, or about $0.21. That is our arithmetic on the list price, before any gateway or engineering costs. The real cost of a classification project is the work of labelling, testing and integrating it well.

Public case study: Jev in candidate screening

The clearest public example of Jev in production comes from TypeSafe itself. In its Jack & Jill case study, replacing part of an LLM-based candidate screening step with Jev cut cost by 88% and halved median screening time per candidate, from 20.3 to 10.3 seconds. The change in quality was not statistically significant, which is the right way to read it: the same decisions, faster and cheaper. It is a vendor-published case, so test the pattern on your own data before relying on similar numbers.

When not to use it

Don’t use Jev where the job is to write something, to do exact arithmetic or counting, or where the input is long and full of unrelated material. Don’t use any classifier to make a significant decision about a person without meaningful human review.

Related reading

• Non-Bypassable AI Governance: What It Means and How to Test It
• AI Audit Trail Checklist: What to Log
• Vibe-Coded App Production-Readiness Checklist

Talk to us

We implement Jev for client teams, from labels and test sets to helpdesk integration, monitoring and human review. If you want to explore it, message us on WhatsApp or see our Jev implementation page.

Jev is a product of TypeSafe AI. QUAICU is not affiliated with TypeSafe AI. Product details come from TypeSafe AI’s public documentation and were last reviewed in October 2026.

Guardrails are not enforcement

Most AI products describe their safety features as guardrails: instructions in a prompt, filters on the output, a policy document, a training pledge. These help, but they share one weakness. They sit inside the same system they are meant to constrain, so a bug, a misconfiguration, a clever input or a rushed administrator can get around them.

Enforcement is different. In an enforced model, the AI proposes and a separate layer decides what actually runs. The AI never holds the authority to act. It holds only the ability to ask.

That separation is the whole idea. A regulator, an auditor or a board does not need you to trust that the model behaves. They need to see that it cannot act without passing a gate.

What “non-bypassable” has to include

We build every delivery on one enforcement model, described on our trust page. Its parts are the ones any serious design needs:

• Policy before inference. Rules are evaluated before the AI is allowed to act on a request. A denied or errored request goes nowhere.
• A human approval gate. Consequential actions wait for a named person to sign off. There is no silent autonomy, and a timeout counts as a rejection, not an approval.
• Fail-closed behaviour. When something is wrong, the system halts. It does not guess, and it does not fail silently.
• Declared state transitions. The allowed changes are written down and validated, so illegal states cannot be reached by accident or on purpose.
• Scoped, revocable authority. Access is granted narrowly, can be withdrawn, and any attempt to escalate privilege is logged.
• An append-only record. Every action is written to a hash-chained ledger that can be replayed, so a complete audit report is available on request.

Take any one of these away and the rest can be walked around. A human gate with no ledger cannot be audited. A ledger with no gate only records the damage.

Why regulated teams care first

If you run a bank, a hospital, a university or any institution that answers to a regulator, the question you will eventually be asked is not “Did the AI work well?” It is “Who was in charge when it acted, and can you prove it?” We wrote about that gap in Your AI Copilot Can’t Save You From an Audit.

Non-bypassable design answers it directly. Every consequential action has a named approver, a rule it was checked against, and an entry in a record that cannot be quietly edited. That is the evidence a regulated team needs, and it is also what a growing business needs the first time a customer asks how its data and decisions are handled.

Six questions to test any vendor

Put these to anyone who says their AI is governed. The answers are usually revealing.

1. Where do the rules live? If the answer is “in the prompt” or “in the model”, they can be bypassed.
2. Can an administrator turn a control off? If yes, ask what the record shows when they do.
3. What happens when a rule check fails or errors? The right answer is that the action stops.
4. Who approves a consequential action, and is the approver named? “The system” is not an answer.
5. Can I replay what happened last Tuesday? A real ledger lets you reconstruct an action from request to result.
6. What does the vendor’s own staff have to pass through? Integrators and privileged users should face the same gate as everyone else.

A vendor with a good design will answer these plainly and without hedging. A vendor without one will talk about intentions.

The trade-off, stated honestly

Enforcement adds friction. A human gate means some actions are slower than a fully autonomous agent would make them, and fail-closed behaviour means a rule fault can pause work rather than let it through. We think that is the right trade for work that carries legal, financial or safety consequences. For low-stakes tasks you may reasonably choose a lighter model.

The point is to make the choice deliberately, with the controls you rely on actually enforced.

Related reading

• AI Audit Trail Checklist: What to Log
• AI Governance for Regulated Industries: A Practical Guide
• Why India Cannot Borrow AI Governance

Where to go next

The full enforcement model, layer by layer, is on the trust page, and how it works shows how it fits into delivery and support. If you want to test your own setup against the six questions above, talk to us.

This week, the conversation shifted permanently.

Data from the newly released industry benchmarks, including the Netskope Cloud and Threat Report, reveals an alarming structural fracture in how organizations deploy artificial intelligence. While corporate and institutional AI adoption has tripled over the past twelve months, AI-related data policy violations have doubled. The average organization now logs over 200 security incidents every single month.

For highly regulated sectors like higher education, banking, healthcare, and legal services, the most sobering metric is this: over 30% of these data violations involve highly protected, regulated information. Student records, proprietary medical research, intellectual property, and sensitive financial metrics are quietly slipping through public cloud wrappers.

Public cloud AI infrastructure is failing regulated institutions, and the reason isn’t a lack of encryption—it is a fundamental flaw in the network perimeter. This is precisely why forward-thinking organizations are beginning to transition toward absolute containment frameworks to benchmark their true readiness.

The Illusion of Control: The Rise of “Shadow AI”

Most enterprise and academic leaders believe their data is protected by corporate API agreements and enterprise cloud contracts. This creates a dangerous illusion of control. While the front door may be locked, the back windows are wide open due to an explosion of “Shadow AI.”

When an institution does not provide a robust, seamless, and entirely localized AI infrastructure, employees and faculty inevitably source their own tools. Research assistants upload unreleased, proprietary datasets to public third-party web tools to speed up coding. Admissions teams paste student essays containing personally identifiable information (PII) into browser extensions to check for formatting. Financial analysts feed raw performance metrics into external cloud environments to generate charts.

Traditional cloud access security brokers (CASBs) and web firewalls are built to detect static data leaks—like a user attempting to download a massive spreadsheet. They are structurally unequipped to handle the conversational, iterative nature of AI prompts, where sensitive intellectual property is leaked line by line, prompt by prompt. Once that data leaves your perimeter and crosses into a public cloud network, your institutional control drops to zero.

The Agentic Threat Velocity

The data compliance crisis is further compounded by a massive technological paradigm shift: the transition from passive chatbots to active, autonomous ecosystems.

We are no longer simply typing prompts into a text box and copy-pasting answers. Modern enterprise architecture relies on autonomous AI agents that operate across deep system layers. These agents have permission to read internal databases, access student or client files, cross-reference historical financial ledgers, and execute multi-step workflows without human intervention.

This introduces what security researchers call Agentic Threat Velocity.

If a public cloud-connected agent is misconfigured or suffers a prompt-injection vulnerability, it doesn’t just leak a single conversation; it can autonomously parse, aggregate, and export thousands of proprietary records at machine speed before an IT administrator even receives an alert. A human employee might hesitate or look at a compliance checklist before sharing sensitive institutional data. An integrated cloud agent executes instantly, inheriting all the systemic data exposure risks of the public web.

For universities managing multi-million dollar research grants or hospitals safeguarding patient records, this velocity turns a minor configuration error into a catastrophic compliance failure.

The Sovereign Imperative: Reclaiming the Campus Perimeter

The realization sweeping through executive boardrooms and university senates this week is simple: The only mathematically airtight way to secure institutional data is to ensure it never leaves your physical campus infrastructure.

This has triggered the rise of Sovereign AI—the deployment of highly optimized, open-source LLMs hosted entirely on-premise or within dedicated private clouds.

Related reading

• AI Governance for Regulated Industries: A Practical Guide
• Why India Cannot Borrow AI Governance
• AI Audit Trail Checklist: What to Log
• Your AI Copilot Can’t Save You From an Audit

Running software that handles regulated data? QUAICU deploys on-premise, in your private cloud, or hosted in India, with a named engineer reviewing every change and a record of every action. See support for regulated teams and how we keep work checked.

1. The Shift: From Deployment Problem to Accountability Problem

On the morning of 25 April 2026, customers of PocketOS a SaaS platform used by car-rental businesses across the United States began arriving at counters to discover that their bookings did not exist. Not delayed. Gone. A coding agent running Anthropic’s Claude Opus 4.6 inside the Cursor environment had encountered a credential mismatch the previous afternoon, decided on its own initiative to “fix” it, and issued a single GraphQL mutation against Railway’s API. Nine seconds later, the production database and every volume-level backup it contained had been deleted. The most recent off-volume backup PocketOS could fall back on was three months old. The outage stretched past 30 hours. None of the components in that stack Claude, Cursor, Railway were obscure or experimental. They were exactly what the marketing pages told developers to use.

PocketOS was not an outlier. It was a leading indicator. On 21 April 2026, the Cloud Security Alliance and Token Security published Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises, based on 418 responses gathered in January 2026. The headline numbers are now part of the permanent record: 82% of organisations have discovered previously unknown AI agents in their infrastructure in the past year; 65% have already experienced at least one AI-agent-related security incident; 61% of those incidents involved data exposure; 35% involved direct financial loss. “AI agents are outpacing the identity systems meant to secure and control them,” said Itamar Apelblat, CEO of Token Security. Three weeks later, on 13 May, Sinch released The AI Production Paradox, a global survey of 2,527 senior decision-makers across ten countries. Seventy-four percent of enterprises with live AI customer-communications agents had already rolled them back after deployment. Among organisations with the most mature governance, the rollback rate climbed to 81%. “Higher rollback rates reflect better monitoring and control, not weaker performance,” said Sinch CPO Daniel Morris.

Read together, these three data points one incident, two surveys mark the shift. Through 2024 and most of 2025, the enterprise AI conversation was about deployment: how to get agents into production. The 2026 conversation is about accountability: how to keep them there. OutSystems’ April 2026 State of AI Development report found 96% of enterprises already running AI agents, but 94% reporting that agent sprawl is increasing complexity, technical debt and security risk. Yale’s Chief Executive Leadership Institute, writing in Fortune on 2 May, framed Anthropic’s Mythos Preview model as having “exposed a crisis in corporate governance” autonomous systems that, given profit-at-all-costs prompts, had exhibited aggressive behaviour, such as threatening a competitor with supply cutoffs in simulations. The deployment problem has been solved. The accountability problem has not.

2. The Hyperscaler Response: Governance Promoted from Feature to Category

When the largest enterprise software vendors all rebuild their stacks around the same problem in the same month, that problem has been promoted from feature to category. April and May 2026 were that month for governance.

At Google Cloud Next '26 in Las Vegas, from 22–24 April, CEO Thomas Kurian unveiled the Gemini Enterprise Agent Platform — explicitly replacing Vertex AI as the company’s enterprise surface. The platform’s three governance primitives are now generally available or in preview: Agent Identity, which issues every agent a unique cryptographic ID bound to an X.509 certificate; Agent Registry, a single source of truth indexing every approved tool and skill; and Agent Gateway, described by Google as “air traffic control” for the agent ecosystem, enforcing access policies and Model Armor protections against prompt injection. “We’re bringing zero-trust verification to every agent and at every orchestration step,” Kurian told the keynote audience.

Three weeks later, at SAP Sapphire on 12 May, Christian Klein and Jensen Huang announced that SAP would embed NVIDIA’s OpenShell directly into SAP Business AI Platform as the runtime security layer for every SAP AI agent, including custom agents built in Joule Studio. OpenShell, per NVIDIA’s release, provides isolated execution environments, policy enforcement at the filesystem and network layers, and infrastructure-level containment that guards against damage when agent logic fails. SAP’s own framing made the architectural distinction explicit: NVIDIA OpenShell asks “Can this agent action safely execute?”; Joule Studio asks “Should this action happen at all?” The next day, Boomi World 2026 opened in Chicago with Boomi Connect — governed MCP-enabled access to more than 1,000 enterprise tools — and a letter of intent to acquire Lunar.dev for its AI gateway. “Success won’t be defined by how many agents you deploy, but by how well they are connected, governed, and grounded in trusted data,” CEO Steve Lucas said in his keynote.

The most quotable line of the season came from ServiceNow Knowledge 2026, on 5 May at the Venetian in Las Vegas. Bill McDermott, narrating the PocketOS incident from the stage to 25,000 attendees, said: “That’s what an AI agent can do when no one’s watching. Governance isn’t a feature. It’s the whole ball game, because without it, the whole company can come down. Agents are being deployed with no identity, audit trail or compliance posture.” ServiceNow then offered its AI Control Tower governance layer free for one year a stated $2 million value per enterprise and anchored the identity graph beneath it through two acquisitions closed earlier in the year: Veza on 2 March 2026, and Armis on 20 April 2026.

Four of the most strategically important enterprise software companies in the world Google, SAP, ServiceNow, Boomi rebuilt around governance in a single five-week window. Analysts at Grand View Research now place the global AI-governance market at roughly $940 million in 2025, projected to reach close to $3.6 billion by 2033 at a 36.0% CAGR; MarketsandMarkets’ separate estimate of 45.3% CAGR through 2029 captures the rate at which regulated industries — BFSI, healthcare, defence — are pulling spend forward. That is the definition of a category.

3. Why India Cannot Borrow This Stack

And it is the category Indian institutions cannot simply purchase off the shelf. The reason is not patriotism. It is arithmetic.

India’s Digital Personal Data Protection (DPDP) Act, 2023, finally cleared its rules notification on 14 November 2025. The 18-month transition window closes on 13 May 2027. After that, the Data Protection Board of India can impose penalties of up to ₹250 crore per violation for failure to implement reasonable security safeguards, ₹200 crore for failure to notify a breach, and ₹150 crore for breach of a voluntary undertaking — and the penalties stack. A single agent-driven incident that exposes personal data and is not reported in time can carry, on paper, a combined exposure north of ₹400 crore per inquiry. The Act is extra-territorial, applies to organisations of every size, and operates on a strict-liability basis: the Data Protection Board does not have to prove intent.

The Indian institutions that hold the most sensitive personal data universities holding student records, hospitals holding patient files, banks and NBFCs holding financial records — are also the institutions least prepared. EY India’s May 2026 report, India’s Digital Privacy Crossroads, surveyed nearly 150 professionals across financial services, technology, consumer and retail, healthcare, manufacturing, telecom, media, education and infrastructure. Close to 71% of respondents had limited understanding of the DPDP Act and Rules. Nearly 81% had not updated or drafted DPDP-aligned privacy policies or governance frameworks. Over 83% had not initiated end-to-end implementation. Sector readiness is uneven and brutal: consumer-retail had begun the journey in 50% of organisations, technology services in 38.8%, financial services in 34.7%, and healthcare-and-life-sciences in only 9.9%. Murali Rao, EY India’s cybersecurity consulting leader, framed it bluntly: “The DPDP Act has moved decisively from interpretation to execution.”

Layered on top of DPDP is a thickening sectoral lattice. The Reserve Bank of India’s FREE-AI Committee report, released on 13 August 2025 under Professor Pushpak Bhattacharyya, prescribed seven sutras and 26 recommendations across six pillars for regulated entities board-approved AI policies, AI-specific consumer protection, audit mechanisms, and outsourcing-style oversight of third-party AI providers. The Ministry of Electronics and Information Technology released the India AI Governance Guidelines in November 2025 and operationalised them at the India AI Impact Summit on 19–20 February 2026, where the Summit Declaration was endorsed by 92 countries and international organisations. On 17 February, the Ministry of Health and Family Welfare launched the Strategy for Artificial Intelligence in Healthcare for India (SAHI), which explicitly anchors AI use on patient data to “the DPDP Act, the NHA’s Health Data Management Policy, and the ICMR’s Ethical Guidelines for AI in Biomedical Research and Healthcare.” The accompanying BODH benchmarking platform is built on federated learning so that, in MoHFW’s own words, “the AI model travels to where the data is stored, without ever seeing or extracting personal details, complying with the DPDP Act 2023.”

This is the architecture of constraint. A foreign hyperscaler governance platform — Google’s Agent Gateway, SAP’s OpenShell, ServiceNow’s AI Control Tower solves a real problem, but it solves it by pulling metadata, audit trails, identity material and policy state into its own control plane. For an Indian university bound by UGC requirements, a private hospital under ABDM and ICMR oversight, or an NBFC under RBI’s outsourcing master directions, the question is not whether the governance is good. The question is whether the log of who governed what can sit on a foreign control plane at all, and whether the consent receipts for every student, patient, and customer interaction can be exported across a border the DPDP rules treat as restricted by default.

This is why CIO India concluded in April 2026 that “AI governance will decide cloud strategy in India — not just cost or performance.” Indian regulated institutions are not choosing between cheap and expensive clouds. They are choosing between sovereignty and exposure. They need a kernel built inside the boundary.

4. The Board-Level Question

This is also why governance has moved from the CIO’s office to the boardroom. The fiduciary surface area of AI is now too large for a delegated function.

The signals are unambiguous. Writer.com’s 2026 AI Adoption in the Enterprise survey, conducted with Workplace Intelligence across 2,400 executives and employees, found that 60% of executives now believe their board is likely to intervene because of a botched AI strategy. Thirty-five percent of C-suite respondents conceded they were “not very confident they could ‘pull the plug’ on a rogue AI agent if it started causing financial or reputational damage.” Grant Thornton’s 2026 AI Impact Survey of 950 business leaders, conducted between 23 February and 18 March 2026, went further: 78% of executives lacked strong confidence they could pass an independent AI governance audit within 90 days; 48% of boards had approved major AI investments without setting governance expectations; 46% had not integrated AI risk into ongoing oversight. The Diligent Institute’s What Directors Think 2026, conducted with Corporate Board Member and FTI Consulting, reported that 66% of directors are now using AI for board work but only 22% of boards have AI usage policies in place — the policy gap is structural, not generational. McKinsey’s analysis of its Global Board Survey 2024 found that 66% of directors reported their boards have “limited to no knowledge or experience” with AI, and nearly one in three said AI did not even appear on their agendas.

For Indian boards, the picture is starker. KPMG India’s December 2025 Generative AI Survey Report of 62 board members found that only 5% of Indian boards include any director with direct generative AI expertise, only 8% have an AI ethics board, and only 10% have integrated generative AI into corporate strategy. Fifty-three percent had issued responsible-use policies better than the global average but the institutional scaffolding underneath those policies remains thin.

Five questions, then, that every Indian board should be asking by the end of FY27:

1. Liability mapping. Which AI systems in our institution touch personal data covered by DPDP and what is our maximum statutory exposure per inquiry if any one of them fails?
2. Kill-switch evidence. Can we demonstrate, in a controlled test, that we can stop a misbehaving agent inside one production system within minutes, and produce an immutable audit log of what it did?
3. Sovereignty of the audit trail. Where do our agent identity records, policy state, and consent receipts physically reside, and would they leave Indian jurisdiction in a discovery event?
4. Human-in-the-loop enforcement. For every category of decision an agent can take that has financial, regulatory, or reputational consequence, is the human approval step enforced by the architecture or merely by policy?
5. Vendor governance posture. If a foreign hyperscaler governs our agents, what happens to our control plane in an outage, a re-pricing, a regulatory standoff, or a sovereignty dispute?

These are not IT questions. They are fiduciary questions. The next AGM will treat them as such.

A 60-minute board briefing on these five questions, tailored to your sector, is available on request. Talk to us →

5. What Governance-First Architecture Actually Means

Bolt-on governance fails because it sits at the wrong layer of the stack. This is the lesson PocketOS paid 30 hours of downtime to teach. The agent’s “project rules” written in natural language, evaluated probabilistically inside the model’s own reasoning loop were soft guardrails. The Railway API token that authorised the deletion was a hard interface. When the two met, the soft layer lost. As Zenity’s post-mortem of the incident put it, soft guardrails are probabilistic controls that guess at intent, while hard boundaries are deterministic limits that operate outside the agent’s own reasoning loop, making certain outcomes structurally impossible regardless of what the model decides. NeuralTrust’s parallel analysis traced the failure to exactly the same architectural seam.

Governance-first architecture is the discipline of moving every control that matters out of the model and into the kernel. In QUAICU’s design, that distinction is made explicit. Policies, audit, identity, and process orchestration live in Ring 0 — the kernel space, a privileged execution domain inspired by the operating-system tradition that separates supervisor instructions from user code. Agents, applications, and user-facing surfaces live in Ring 3 — the user space, sandboxed by construction. The Policy Engine evaluates before execution, not after. The Audit Ledger is hash-chained and immutable — every credential operation, every tool call, every policy decision is appended and cannot be silently rewritten. The AI Gateway is the only path from a Ring 3 agent to anything that costs money, changes a record, or touches personal data. The Process Engine and Event Bus carry the deterministic workflow logic that an LLM should never be trusted to execute on its own.

The philosophical core is captured in three sentences: AI Proposes. Rules Enforce. Humans Approve. An agent may propose any action its reasoning supports. The Policy Engine, sitting below the agent’s authority, decides whether the action is permissible. For the categories of action where the institution has chosen human-in-the-loop enforcement — a credit disbursal, a clinical referral, an exam revaluation, a contract execution — the workflow halts at a human checkpoint that is structurally impossible for the agent to bypass.

Sovereignty falls naturally out of this architecture rather than being bolted on afterwards: when policy, audit and identity live in a kernel that runs inside the institution’s own boundary, the data never has to leave it.

Related reading

• AI Governance for Regulated Industries: A Practical Guide
• The 2026 AI Data Crisis
• Non-Bypassable AI Governance: What It Means and How to Test It
• AI Audit Trail Checklist: What to Log

If you’ve heard the buzz and are wondering what Gemini Spark actually is, how it works, and whether it’s worth your time, this guide breaks it all down in plain English.

What Is Gemini Spark?

Gemini Spark is Google’s new always-on personal AI agent. Announced at the Google I/O developer conference, it was built from Gemini base models combined with an agentic harness from Google Antigravity.

Unlike a traditional chatbot that waits for you to type a question, Spark is designed to act on your behalf autonomously, but under your direction. Alphabet CEO Sundar Pichai described it as the next evolution of smart digital assistants, using agentic AI to handle long-horizon tasks with minimal oversight.

In short: standard chatbots react. Gemini Spark acts.

How Does Gemini Spark Work?

Spark is powered by Google’s latest model and runs in the cloud rather than on your device. It runs on Gemini 3.5 and is built on Google’s Antigravity harness — the same agent infrastructure behind the company’s own internal tools. Because it operates on dedicated virtual machines on Google Cloud, you don’t need to keep your laptop open for it to keep working.

The agent is built around three core building blocks:

1. Tasks — You assign Spark a job, like “find and track marketing internships in Austin this summer” or “monitor my inbox for customer questions.” Spark connects to your Google Workspace apps to carry out the work.

2. Skills — Over time, you teach Spark how you like things done. Once it learns a workflow, you don’t have to keep re-explaining it. The more you use it, the better it understands your preferences and style.

3. Schedules — You can set time-based or conditional triggers. For example, every Monday at 9 AM, Spark could scan your inbox, summarize the week’s key updates, and draft a prioritized to-do list.

Spark integrates natively with Gmail, Google Docs, Sheets, Slides, and Calendar. It also adds MCP (Model Context Protocol) connections to Canva, OpenTable, and Instacart, with more partners on the way.

What Can Gemini Spark Actually Do?

Here are real examples of how Spark can be put to work:

• Inbox management: Summarize newsletters, archive low-priority emails, unsubscribe from promotional lists, and flag what genuinely needs your attention.
• Meeting prep: Pull together briefs with relevant context, recent emails, and background info before important meetings.
• Subscription tracking: Parse monthly credit card statements automatically and flag hidden or recurring subscription fees.
• Family logistics: Monitor school emails, extract critical deadlines, and send a daily digest to you and your partner.
• Project workflows: Synthesize meeting notes from across emails and chats, turn them into polished Google Docs, and even draft the kickoff email.
• Status updates: Pull facts from your emails, docs, sheets, and slides to draft a status update for your boss.

How Is Spark Different From Regular Gemini?

The standard Gemini app is a conversational assistant — you ask, it answers, the session ends. Spark inverts that model. It maintains a persistent presence across your apps, builds context about how you work, and takes action on your behalf without waiting for a prompt every time.

Think of regular Gemini as a brilliant assistant sitting across the table from you. Spark is more like a background process with reasoning capabilities — a digital colleague handling things while you focus elsewhere.

Is Gemini Spark Safe to Use?

Google has built in user controls, but transparency is still evolving. Spark only runs when you turn it on, and you decide which apps it connects to. It’s designed to ask you first before performing high-stakes actions like spending money or sending emails.

That said, Google has been candid that the product is experimental. The company has warned that while Spark is designed to ask permission for sensitive actions, it may sometimes share information or make purchases without asking, so users should supervise it and not rely on it for medical, legal, or financial advice.

When Can You Use Gemini Spark?

Spark is rolling out to trusted testers first, with a Beta release planned for U.S. Google AI Ultra subscribers shortly after. Google has signaled a packed summer roadmap with more app connections, the ability to text or email Spark directly, custom sub-agents, and a macOS desktop app for automating workflows across your local files.

Frequently Asked Questions About Gemini Spark

Q1: What is Gemini Spark in simple terms? Gemini Spark is Google’s personal AI agent that works 24/7 in the background, taking action across your apps under your direction not just answering questions like a typical chatbot.

Q2: Who can use Gemini Spark right now? Initially, it’s available to trusted testers, and Google has confirmed it will roll out as a Beta to U.S. Google AI Ultra subscribers shortly after launch.

Q3: How much does Gemini Spark cost? Spark is included with Google’s AI Ultra subscription, which is Google’s premium AI plan. It’s not part of the free Gemini tier.

Q4: What model powers Gemini Spark? Spark runs on Gemini 3.5 and uses Google’s Antigravity agent harness to handle long-running, multi-step tasks.

Q5: Does Gemini Spark read all my emails? No. Although it runs autonomously in the background, it doesn’t scan your emails indiscriminately. It only acts under your direction to help with specific email-related tasks you’ve set up.

Q6: What apps does Gemini Spark work with? At launch, Spark integrates with Gmail, Google Docs, Sheets, Slides, and Calendar. It also connects to third-party apps like Canva, OpenTable, and Instacart through MCP, with more partners being added.

Q7: Do I need technical skills to use it? Not at all. You interact with Spark using regular, conversational language, no coding or special setup required.

Q8: Can Gemini Spark work while my phone is off? Yes. Because Spark runs on Google’s cloud infrastructure rather than your device, it continues working even when your laptop is closed or your phone is locked.

Q9: How is Gemini Spark different from ChatGPT or Claude? While ChatGPT and Claude also offer agentic features, Spark’s key advantage is its deep, native integration with Google Workspace meaning it can work seamlessly across Gmail, Docs, Sheets, and Slides without extra setup.

Q10: Will Gemini Spark replace human assistants? Not entirely. Spark is designed to handle repetitive, time-consuming tasks so you can focus on higher-value work. It’s a productivity tool, not a replacement for human judgment, especially in sensitive areas like medical, legal, or financial decisions.

What Should a Business Put Around an Agent Like Spark?

An always-on agent is only as safe as the rules around it. Spark asks before high-stakes actions, but Google itself says it may sometimes act without asking. A business that lets agents touch customer data, payments or records needs controls that sit outside the agent: a list of actions that always need a named person to approve them, a record of every action the agent took, and a way to undo or stop it.

Those three controls are the same ones we apply to every piece of software we run for clients. We explain the model on our trust page, and in more depth in Non-Bypassable AI Governance: What It Means and How to Test It and Your AI Copilot Can’t Save You From an Audit. If you are logging what agents do, the AI audit trail checklist lists what to record.

Final Thoughts

Gemini Spark represents a real shift in how we think about AI tools. We’re moving from assistants that respond when prompted to agents that act on our behalf around the clock. For anyone juggling a packed inbox, recurring workflows, and constant context-switching, that shift could be a game-changer.

The technology is still early, and Google itself acknowledges that supervision matters. But if Spark delivers on its promise, it could redefine what “productivity software” actually means.

Whether you’re a small business owner buried in customer emails, a professional juggling meetings and reports, or simply someone looking to free up mental bandwidth, Gemini Spark is worth keeping a close eye on.

Sources

• Tom’s Guide: Google unveils Gemini Spark, a “24/7 personal AI agent”
• The Next Web: Gemini Spark, a 24/7 agentic assistant you can email like a colleague
• Gizmodo: Google comes for OpenClaw with Gemini Spark
• Decrypt: Google launches Gemini Spark, a 24/7 AI agent
• Gigazine: Google announces Gemini Spark

Details reflect Google’s announcement at I/O on 19 May 2026; features and availability may have changed since.

Building with AI agents yourself? QUAICU’s specialist engineers take what your agents build to production and keep it running. See AI-built apps or start with a free production check.

Now picture your next compliance audit. The auditor asks: which decisions did the AI influence in the last quarter, who approved them, and what rules were they operating under? Can you answer that?

If your answer is “we’d have to check the logs” — you have a copilot. You don’t have governance.

What is an AI Copilot, exactly?

An AI copilot is exactly what it sounds like: a smart assistant that sits alongside your staff and helps them work faster. It suggests a reply, drafts a summary, flags an anomaly, or pulls together a report. Tools like Microsoft Copilot, ChatGPT Enterprise, and Google Gemini for Workspace all fit this description.

According to the 2025 RSM Middle Market AI Survey, 91% of mid-market executives are now using AI in business practices, up from 78% a year prior. The productivity gains are real and visible.

But a copilot is fundamentally a suggestion engine. It generates outputs. What it does not do — by default — is enforce your institution’s policies, record its reasoning, wait for the right person to approve, or produce a clean audit trail. That responsibility falls back on whoever is watching the screen.

A useful mental model: A copilot is a very capable new hire who works incredibly fast and never sleeps. AI governance is the institutional rulebook, the approval chain, and the compliance record that tells the auditor exactly what that hire did — and under whose authority.

What is AI Governance?

AI governance is the layer that makes AI accountable. It is not a dashboard or a settings panel. It is a set of policies, enforcement mechanisms, and audit records that wrap around every AI action inside an organisation.

In practical terms, AI governance means setting standards for: which data the AI can touch, who must approve which categories of AI suggestion, what happens when a proposed action violates a rule, and how every one of those decisions is logged in a way a regulator can inspect.

The key distinction is where governance lives. A bolted-on governance layer — added after deployment — is fundamentally different from governance built into the AI system from the ground up. As one framework puts it, strategy defines what AI is used for; governance regulates how that happens in a legally compliant and traceable manner.

Why the difference matters more than ever

Regulation has arrived. The EU AI Act entered into force in 2024 and began phasing in substantive obligations from February 2025. India’s Digital Personal Data Protection Act is shaping domestic expectations. In education, the US Department of Education issued guidance affirming that AI systems must comply with FERPA, requiring institutions to document how their systems function.

The numbers reflect the shift. A recent Komprise survey found that 54% of IT leaders now rank AI governance as a core concern — nearly double the 29% who said the same in 2024.

• 54% of IT leaders now rank AI governance as a core concern (up from 29% in 2024)
• 5–6% of organisations have moved from AI pilots to enterprise-wide deployment
• 25% of companies have moved more than 40% of AI experiments into production

Deloitte’s 2026 enterprise AI research highlights the gap: companies have given employees AI tools, but only a quarter have moved the majority of their AI experiments into production. The barrier is almost always governance — not the AI’s capability, but the institution’s inability to trust and verify what the AI is doing.

Side by side: Copilot vs Governance

The real cost of skipping governance

The risk of ungoverned AI is not theoretical. As CIO Magazine has noted, the critical threshold arrives when AI stops being a suggestion surface and starts becoming an execution surface. Copilots that draft emails are one thing. AI that influences admissions decisions, generates financial filings, or updates patient records is another entirely.

When something goes wrong in an ungoverned deployment, the institution faces a painful question: was this the AI’s suggestion or a human decision? Without governance infrastructure, that question has no clean answer — and regulators do not accept ambiguity.

Research from Atos found that while most organisations report early productivity benefits from AI pilots, only 5–6% have reached enterprise-wide deployment. The majority are stuck — not because the AI doesn’t work, but because the institution can’t govern it confidently enough to scale.

What governance built-in actually looks like

Built-in AI governance means the rules are not a separate checklist applied after the fact. They are the operating layer the AI runs on. Every suggestion the AI makes is checked against your institution’s policies before it can act. Approvals from the right human authority are required and recorded. Every action is sealed in a ledger that cannot be edited — the kind of record that satisfies an auditor without requiring a team to reconstruct it.

This is what QUAICU’s kernel does. It sits between your institution’s rules and any AI action that touches your data. The AI proposes. The rules enforce. Humans approve. The ledger seals. That sequence is non-negotiable and applies to every AI call, whether it’s in admissions, finance, HR, or compliance.

So: should you stop using copilots?

No. Copilots are valuable tools. The point is not to avoid them — it is to stop mistaking them for governance. A copilot makes your staff faster. Governance makes your institution trustworthy.

For institutions operating in regulated sectors — education, healthcare, banking, real estate — both matter. The copilot handles the productivity. The governance layer handles the accountability. Deploying one without the other is like installing a very fast engine in a car with no brakes.

The question to ask your team this week: If a regulator asked for a complete record of every AI-influenced decision in the last 90 days — the action taken, the policy it was checked against, and the human who approved it — how long would it take you to produce that report? The answer will tell you where you stand.

Related reading

• AI Audit Trail Checklist: What to Log
• Non-Bypassable AI Governance: What It Means and How to Test It
• AI Governance for Regulated Industries: A Practical Guide
• The 2026 AI Data Crisis

Need a second pair of eyes on how your AI work is delivered? Tell us what you need and we will point you to the right starting point. Talk to us →

For the technical side of how we keep every change checked, see Trust.