By Abhishek G Sharma
On June 11, 2026, Tata Consultancy Services and Anthropic announced a partnership that would give Claude access to 50,000 TCS employees across 56 countries and support Claude powered products for sectors including financial services, healthcare and the public sector.
The following day, Anthropic said the U.S. government had issued an export control directive requiring suspension of all access to Fable 5 and Mythos 5 by foreign nationals, and that the company had to disable both models for all customers to ensure compliance. Anthropic said access to its other models was not affected.
This timing should not be read as an argument against Anthropic, TCS or foreign AI vendors. The TCS announcement concerned Claude broadly, not a claim that Indian enterprises had deployed Fable 5 or Mythos 5 into production. That distinction matters.
The sharper lesson is operational. When an enterprise relies on AI features embedded inside another vendor’s software, it may not know which frontier model sits underneath the feature, what data reaches it, where it is processed, whether the provider can change, or what happens if access is restricted.
For Indian CIOs, CISOs, procurement teams and legal teams, this is now a practical vendor risk question, not a theoretical AI policy debate.
Embedded AI changes the software supply chain
Most enterprises will not consume frontier AI models directly. They will not always sign a contract with a model provider, configure a model endpoint, or review model documentation. Instead, they will enable AI features inside SaaS platforms, cybersecurity products, analytics tools, developer environments, customer support systems, office suites and workflow automation platforms.
The AI may arrive as a feature toggle. The contract may remain a SaaS contract. The internal approval may say “AI enabled feature” rather than “new model dependency”.
That is no longer enough.
When a vendor embeds a frontier model into a product, the enterprise inherits a fourth party dependency it may not have inspected. A business application may be sold by one vendor, hosted by a cloud provider, connected to a frontier model from another provider and enhanced by retrieval, automation or agentic workflow components from additional vendors. The enterprise may see only the primary software interface.
That creates a procurement blind spot.
A customer support product may use an external model to summarise tickets. A development tool may use a model to generate code or explain vulnerabilities. A cybersecurity platform may use a model to classify alerts. A finance workflow system may use a model to draft exception notes. A HR product may use a model to screen, summarise or rank employee facing information.
In each case, the enterprise risk is not limited to the visible vendor. It also includes the model provider, data path, retention setting, sub processor route, model update cadence, prompt and output logging, fallback process and customer notification commitment.
The lesson from the Fable 5 and Mythos 5 disruption
The Fable 5 and Mythos 5 incident is useful because it gives enterprise buyers a live example of model access risk. The lesson is not that every organisation should avoid one provider or rush to another. That would be simplistic.
The lesson is that access to frontier AI capability can change for reasons outside the enterprise’s control. Those reasons may include export controls, provider policy changes, model safety reviews, capacity constraints, pricing changes, abuse investigations, security incidents or strategic product decisions.
Because Fable 5 had only just launched, the event should not be misread as evidence that Indian enterprises were already dependent on that specific model in critical production workflows. It should be read as a warning about a broader pattern that will become more common as frontier models are embedded into ordinary enterprise software.
If an embedded AI feature supports a low impact workflow, loss of access may be inconvenient. If it supports customer service, security operations, software development, fraud review, analytics, legal triage or regulated operational processes, the effect may be larger.
The organisation needs to know where model dependency sits before the dependency fails.
Standard SaaS diligence is too thin
Many vendor questionnaires still ask broad AI questions:
• Does the vendor use AI?
• Is customer data used for training?
• Where is data hosted?
• Is encryption used?
• Is there an incident response process?
These questions are useful, but they do not expose the model path. They do not separate the application vendor from the model provider. They do not identify whether prompts, files or outputs are retained for evaluation, debugging or abuse monitoring. They do not ask whether the vendor can switch model providers without customer notice. They do not ask whether the customer can disable the AI feature without disabling the product.
This is the gap Indian enterprises should close now.
There is also a local governance reason to treat the issue seriously. India’s Digital Personal Data Protection Rules, 2025 reinforce the need to understand how personal data is processed and by whom. In the securities market, SEBI’s May 2026 advisory on emerging AI vulnerability detection tools points to risks around data confidentiality, application integrity, reliability of outputs and third party application service providers.
That does not mean every embedded AI feature is unlawful or high risk. It means model identity, data routing, processor disclosure, change control and fallback evidence are now part of responsible enterprise procurement.
The Frontier AI Vendor Evidence Request
Before approving a material embedded AI feature, enterprise buyers should require a short but specific evidence request from the vendor. It should not become a 40 page legal exercise. It should give business, security, privacy, procurement and legal teams the same factual base for approval.
1. Model identity: Which model, model family or model route powers the feature? Is it proprietary, third party, open weight, self hosted, fine tuned or accessed through an external API?
2. Provider route: Is the model operated by the software vendor, a cloud provider, a frontier AI provider, an integration partner or another sub processor?
3. Feature scope: Which product features use the model? Does the model summarise, generate, classify, recommend, call tools, access records or change workflow state?
4. Data categories: What customer data, personal data, user data, metadata, prompts, outputs, uploaded files, logs or system context can reach the model?
5. Hosting and processing location: Where does model processing occur, and can any data route outside the customer’s expected geography or the vendor’s primary hosting environment?
6. Retention and reuse: Are prompts, outputs, files, telemetry or feedback retained, and are they used for training, evaluation, debugging, abuse monitoring or product improvement?
7. Sub processor and API chain: Which third party model providers, infrastructure providers or integration partners are involved, and how are changes to that list notified?
8. Change control: Can the vendor change the underlying model, provider, region, retention setting or feature behaviour without customer approval or notice?
9. Fallback and disablement: What happens if model access is restricted, degraded or suspended? Can the customer disable the AI feature while keeping the core product running?
10. Evidence retention: What logs, configuration records, approvals, model responses and exception records are available for internal review, incident response, audit or board reporting?
For Indian buyers, the evidence request should also ask whether the vendor can support any sector specific outsourcing, data, cybersecurity or resilience obligations the customer must meet. The point is not to turn procurement into legal theatre. The point is to prevent hidden model dependency from becoming visible only during an incident.
CIOs and CISOs need one approval record
The worst approach is to push this problem entirely to legal or entirely to security.
Legal teams may focus on contract language, privacy terms and processor obligations. Security teams may focus on access, logging, resilience and incident response. Procurement may focus on cost, renewal and vendor concentration. Business teams may focus on speed and functionality.
Embedded AI cuts across all of them.
For any material AI feature, the enterprise should keep a shared approval record that answers eight questions:
• What feature is being enabled?
• Which model or model provider is involved?
• What data can reach the model?
• Who approved the feature?
• What controls are required before use?
• What evidence has the vendor supplied?
• What fallback exists if access changes?
• Who owns ongoing review?
This does not need to slow adoption. It can speed adoption by reducing rework between business, technology, security, privacy, legal and procurement teams. The blocker in many enterprises is not governance itself. It is unclear evidence and unclear ownership.
Boards need the dependency summary, not the architecture
Boards and audit committees should not be expected to review every embedded model architecture. But they do need visibility into material AI dependency.
A useful board question is simple: Which critical vendors have enabled AI features since the last vendor review, and has anyone mapped the underlying model route?
That single question forces a practical summary: which vendors use embedded AI, which business processes depend on those features, which model providers sit behind them, what data categories may be exposed, and what happens if access, model behaviour or provider terms change.
That is enough to move AI oversight from generic enthusiasm to evidence based governance.
The next vendor review question
Indian enterprises are moving quickly on AI. That is commercially necessary. But speed without vendor model disclosure creates invisible dependency.
The next procurement review should not stop at asking whether a vendor uses AI. It should ask what model sits behind the feature, what data reaches it, what evidence exists, what can change, and what happens if the model is unavailable.
Embedded AI is becoming part of the enterprise software supply chain.
It should be reviewed like one.
About the author
Abhishek G Sharma is Founder and CTO of Move78 International and EU AI Compass. He has 20+ years of experience across cybersecurity, cloud risk, technology risk, AI governance and compliance, with work spanning enterprise technology risk, third party risk, ISO/IEC 42001, NIST AI RMF and EU AI Act readiness.