Most enterprise AI doesn't die in the demo. It dies in compliance review.
I'm Aditya, a Salesforce solution architect building Agentforce + Data Cloud systems for banks and insurers in India.
What I keep seeing kill AI projects in BFSI:
1. No audit trail for what the agent actually saw
2. Grounding data nobody owns
3. Consent that doesn't travel with the data
4. Nobody can say which prompt version made the decision
5. Risk teams invited last
What I'll post here: architecture diagrams, anonymised failure post-mortems, and plain-English notes on RBI/AI rules for people who build.
If you ship AI where 'it works' isn't good enough, follow along.
@SalesforceBen Duplicating a skill is the easy part. The hard part is versioning: when someone edits the 'best practice', which agents keep the old copy, and who approved the change? Unmanaged copies are how you end up with twelve slightly different processes, none auditable.
@tuncertan@ThinkinOps The person who can raise an agent's limits shouldn't be the one operating it. In banks that's usually second line or a change board, with a time-bound increase and an automatic rollback. A track record is evidence. It isn't a reason to skip the approval.
@SalesforceBen Suspicious tokens are a symptom. The architect question is whether those Connected Apps had a named owner, a last-reviewed date, and a scope narrower than 'access everything'. Most orgs still treat third-party OAuth as a one-time setup, not a running privilege.
@ThinkinOps The 72-hour clock only works if you know the incident happened. If the agent acts on a path the SIEM never sees, or the vendor log isn't the system of record, you hear it from the regulator first. 'Did they file' is step two. 'Would we even know' is step one.
@emollick The powerloom also brought quality control, standard parts and inspectors. Industrialised knowledge work needs the same: versioned procedures, sampling, defect logs. Banks already run on maker-checker. The open question is who inspects when the checker is also an agent.
@akshay_pachaar Same bug shows up in CRM, minus the graph. Two agents update one customer record, last write wins, and the audit trail shows a clean edit nobody can explain. In regulated systems the merge check isn't a nicety. It's how you prove which agent changed what, from which version.
@ThinkinOps Fair. A lot of maker-checker in banks is ritual, not judgement: the checker signs because the rule says two pairs of eyes. If an agent step is deterministic and fully logged, keep the human for calls that need discretion: exceptions, overrides, credit judgement.
@dhinchcliffe Operating model is the bit everyone skips. A policy doc doesn't stop an agent. A registry of every agent, a named owner, scoped credentials and a kill switch someone has actually tested does. Most CIOs still can't say how many agents are live in production today.
@ankrgyl In regulated industries a trace lake stops being optional. It's the audit evidence: which agent, which version, what it retrieved, what it did. The open question is retention. Traces full of customer data become a privacy liability. Who's redacting at ingest?
@NandanNilekani AA is the most underrated piece for enterprise AI in Indian finance. Consent as a machine-readable artefact with purpose and expiry is exactly what agents need. The gap: most bank CRMs still store consent as a checkbox, so the purpose limit dies at the data lake.
@cxtodaynews An index of the org is only as good as the org. Most enterprise orgs carry years of dead fields, duplicate flows and permission sets nobody can explain. Agents grounded on that inherit the tech debt as fact. Does Catalog flag what's deprecated, or just index it?
@MuleSoft OBO is the right default. The hard part in regulated shops is the audit trail: when an agent acts as the user, the log has to show both identities, or you can't separate a customer action from an agent action later. Does Agent Fabric keep the agent's identity in the chain?
@levie Context access is the easy half. The harder half is entitlements: an agent reading 100x more files needs the same need-to-know rules a human has, enforced at retrieval time, not after. In banks that's the line between a pilot and a production sign-off.
@martinfowler Durable execution fixes recovery, but it raises a question for enterprise systems: if an agent resumes on day three, are the permissions and data it planned on still valid? Checkpointing state without re-checking authorization is how long-running agents drift out of policy.
@emollick RAG didn't die, it got demoted to plumbing. In regulated enterprises the question was never 'can it talk to documents'. It was 'can you prove which version of which document it used'. That part still matters. It just stopped being a product.
@HamelHusain Agree. In regulated work your private eval set is basically your compliance evidence. A bank doesn't care what a model scores on a leaderboard. It cares whether it refused the 40 prompts its risk team wrote. Build that set first, pick the model second.
@jerryjliu0 Insurance is where document AI gets honest. Claims files are scanned, handwritten, half in a regional language. The model is rarely the bottleneck. The confidence threshold that decides when a human looks is. Curious what the room said about that.
@SalesforceDevs@salesforce Versioned agent definitions are what BFSI change boards have been waiting for. They want to diff agent v3 vs v4 before prod. Does AiAgentDefinitionVersion also capture prompt templates and grounding config, or only the topic and action wiring?