# Decision Evidence Dossier: Investment Required Before AI Becomes a Major Consumer of Enterprise Data **Research snapshot: October 3, 2026** **Decision in one sentence:** An organization that already has a warehouse/lakehouse, BI estate, and data team should **not** fund a broad “agent-ready data platform” by default. The most defensible first investment is a **bounded AI-facing access pattern over the existing platform**: deterministic authorization, a curated domain boundary, explicit definitions for the business concepts the AI must answer about, visible freshness/quality state, traceable execution, and a regression evaluation set. Investment should move upstream into the core platform only when observed failures show that those controls cannot be supplied reliably at the access layer. This is consistent with production reports from PAR Technology and OpenAI, and with current Snowflake and Databricks designs, all of which add substantial context, control, and evaluation around existing data systems rather than demonstrating that warehouse replacement is inherently necessary. [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/) The critical distinction is therefore not **“AI-ready versus not AI-ready.”** It is: > **Which AI consumer, doing which job, over which data, with what failure consequence, requires which additional controls?** The evidence does **not** support the proposition that agents require perfect enterprise-wide metadata, an ontology, a knowledge graph, a new catalog, a universal semantic layer, or a redesigned lakehouse before useful experimentation. Conversely, real enterprise text-to-SQL remains materially harder than benchmark demonstrations: Spider 2.0 was constructed from 632 enterprise workflow problems involving large schemas, multiple SQL dialects, metadata, documentation and code context; leading systems performed dramatically worse than on earlier simplified text-to-SQL benchmarks. [2](https://arxiv.org/abs/2411.07763) **Evidence labels used below** - **Empirical:** experimental or benchmark evidence. - **Production:** evidence from a deployed system; where company/provider-published, it is explicitly treated as self-reported rather than independently audited. - **Provider design:** documentation showing how a commercial system is designed; evidence of an engineering pattern, not proof of ROI. - **Normative:** standards, regulation, or formal risk-management guidance. - **Mechanism:** a causal proposition that is technically plausible but not directly quantified. - **Speculative:** potential value for which convincing production or controlled evidence was not found in the primary sources reviewed. ## Leadership decision frame ### The leadership decision map **Deliverable — Leadership decision map** The first leadership decision is the **risk and use-case envelope**, not the technology layer.
Leadership choice Appropriate when What it buys What it does **not** solve Reversibility
Expose existing warehouse directly Expert internal users; sandbox/non-sensitive data; exploration where users can inspect SQL Maximum flexibility, minimum interface engineering Ambiguous metrics, bad joins, inappropriate tables, model-generated access mistakes High
Curated warehouse role/views A bounded domain can be represented through a limited set of trustworthy tables/views Harder data boundary, smaller schema/search space, existing SQL ecosystem Full business semantics or workflow actions **Very high; strong default experiment**
Governed metrics / metric API Repeated KPI questions where consistency matters more than arbitrary exploration Canonical calculations, time/filter semantics, reusable answers Open-ended analysis outside modeled metrics High–medium
Richer documentation/metadata Correct tables exist but users/agents cannot reliably discover or interpret them Better table selection, grain/join/context understanding Incorrect upstream data or ambiguous business policy High
Formal semantic layer Many users/tools repeatedly need the same entities, joins, dimensions, and metrics Central reusable semantic logic Bad source data; permissions; action safety Medium
Data contracts / stronger quality Agent failures arise from unstable schemas, freshness, or upstream changes Earlier detection/prevention of data breakage Business-meaning ambiguity High
Domain-specific agent tools/API Customer-facing or workflow use case has a narrow set of supported operations Strong policy boundary, auditability, validation Arbitrary analysis High
AI-specific access layer Different AI consumers need context retrieval, policy enforcement, tool routing or observability not supplied by the warehouse interface Decouples models/agents from raw platform Structural problems inside core data products Medium–high
Keep AI read-only Analytical benefit exists but action errors have meaningful downside Major reduction in blast radius Wrong answers and disclosure risks **Very high**
Delay access Deterministic authorization, trustworthy source data, or basic ownership cannot be established even for the chosen domain Avoids scaling an uncontrolled failure mode Does not itself remediate debt N/A
The evidence behind the preference for constraining access rather than trusting prompts is unusually concrete. PAR Technology reports that its first production direction was direct natural-language-to-SQL over Databricks. It regarded that version as analytically promising but unsuitable for a multi-tenant production setting, then moved authentication, semantic validation and row isolation outside the model. Its resulting architecture exposes only a preauthorized data sandbox to the LLM. PAR reports more than 50,000 production queries with zero cross-tenant exposure incidents; that figure is a **self-reported production result, not an independent security audit**. [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/) OpenAI describes a different but complementary pattern for its internal data agent: it retained existing data permissions, put the agent in an interface layer, passed through the user's existing table entitlements, and supplied additional context from metadata, lineage, human annotations, pipeline code, institutional knowledge, memory, and live data inspection. Its published architecture therefore shows that substantial AI enablement can occur **without making the AI access layer the system of record or replacing the underlying data platform**. [3](https://openai.com/index/inside-our-in-house-data-agent/) **Decision recommendation:** treat “replace/redesign the platform” as an **escalation**, not the opening assumption. ### What AI changes versus what it merely exposes **Deliverable — What AI changes versus what it merely exposes** A useful distinction is between pre-existing data debt and genuinely new operating requirements.
Weakness Human analyst today AI consumer Classification
Undocumented metric definition Analyst asks a colleague or recognizes dashboard convention Agent may produce a plausible but different calculation Mostly **exposed debt**, amplified
Tribal join knowledge Analyst learns which many-to-many join is dangerous Agent needs this information supplied or must discover it experimentally Exposed debt + machine-context requirement
Undocumented grain Analyst inspects rows or knows the model Incorrect aggregation may look perfectly plausible Exposed debt, higher propagation risk
Exceptions/business rules Experienced analyst remembers them Agent cannot infer company-specific exceptions reliably from generic model knowledge Exposed debt
Stale pipeline/dashboard Human may know “Monday data is late” Agent needs machine-observable freshness or may confidently reuse stale data Exposed debt + new signaling requirement
Conflicting definitions Humans negotiate which one to use Automated consumers can scale inconsistency across many interactions Exposed debt amplified by scale
Inconsistent ownership Humans find “who knows this table” informally Agent cannot reliably escalate or repair governance ambiguity Exposed debt
Stochastic query generation Not applicable to conventional SQL/report Equivalent questions can produce different generated SQL/results **AI-specific operational requirement**
Need for evaluation set Dashboard query is deterministic and testable directly Natural language→reasoning→SQL requires task-level regression tests **AI-specific**
Prompt injection / malicious natural language Not a normal BI query interface Language is both user interface and potential attack surface **AI-specific**
Delegated identity across tools Often a single BI session Agent may call multiple services “on behalf of” a user **AI-specific**
Safe ambiguity handling Analyst asks a clarification Agent needs explicit clarify/abstain behavior **AI-specific**
Tool/action blast radius Human manually moves from insight to action Agent can potentially chain analysis into execution **AI-specific**
OpenAI's engineering report is unusually illustrative of the first half of the table: it cites similar-looking tables, many-to-many joins, missing filters, null handling, table lineage, pipeline logic, freshness and company-specific calculations as challenges that already exist in analytics; it then supplies those contexts explicitly to the agent. [3](https://openai.com/index/inside-our-in-house-data-agent/) The second half is genuinely different. Snowflake's current evaluation tooling explicitly reruns natural-language questions against verified SQL/result sets and warns that repeated generations can differ even when the evaluation judge is pinned; its documentation recommends repeated evaluation to understand normal score variation. That is an operational requirement conventional BI queries do not have in the same form. [4](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst-evaluations) Likewise, authorization cannot become another piece of prompt context. PAR's production architecture deliberately puts data isolation outside the LLM because probabilistic generation is not considered a deterministic policy enforcement mechanism. NIST Zero Trust guidance independently recommends granular resource-level authorization and policy enforcement rather than implicit trust. [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/) **Bottom line:** AI does not magically make poor data poor. It makes **implicit knowledge, nondeterminism, and automated propagation** much more economically relevant. ## Value and use-case evidence ### Value and use-case map **Deliverable — Value / use-case map** There is a major evidence gap worth making explicit: the primary sources reviewed do **not** provide robust, independent evidence that investing in an enterprise semantic layer, catalog, ontology, or “agent-ready platform” produces a universal percentage improvement in business performance. The strongest direct evidence today consists of deployed data-agent reports, text-to-SQL benchmarks and provider engineering practices. Therefore, platform investment should be justified by a named use case and measured against that use case, not by generic claims about “unlocking AI.”
Potential value Evidence status Evidence / interpretation
Broader analytical self-service **Production evidence, provider/self-published** OpenAI reports use across Engineering, Data Science, GTM, Finance and Research and describes employees moving from questions to insights much faster; no controlled ROI estimate is provided. [3](https://openai.com/index/inside-our-in-house-data-agent/)
Natural-language analytics for external users **Production evidence, provider/customer-published** PAR reports a deployed multi-tenant text-to-SQL system and >50,000 queries. This proves feasibility under a constrained architecture, not universal economics. [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/)
Reduced manual context gathering **Production mechanism** OpenAI explicitly retrieves schema, lineage, historical query patterns, annotations, code-derived context and institutional knowledge so the human does not gather all of it manually. [3](https://openai.com/index/inside-our-in-house-data-agent/)
More capable internal assistants **Production + mechanism** OpenAI's internal agent performs discovery, SQL generation and multi-step exploration over its data environment; Databricks likewise documents multi-query agent mode. [3](https://openai.com/index/inside-our-in-house-data-agent/)
Faster operational decisions **Plausible; weak direct causal evidence** Faster analytical retrieval can shorten decision latency, but the reviewed primary sources do not establish a general business-outcome effect size.
AI-assisted data engineering **Adjacent empirical evidence** A 2026 randomized study across Microsoft, Accenture and a Fortune 100 company covering 4,867 software developers found a pooled 26.08% increase in completed tasks from an AI coding assistant. This is strong productivity evidence for software development, but **not a measured effect of making enterprise data agent-ready**. [5](https://pubsonline.informs.org/doi/abs/10.1287/mnsc.2025.00535)
Reusable organizational context **Production mechanism** OpenAI reports reusing annotations, code-derived meaning, institutional knowledge and saved corrections across future analyses. [3](https://openai.com/index/inside-our-in-house-data-agent/)
Agentic business workflows **Plausible / case-dependent** Data access is a prerequisite for many workflows; the business outcome comes from the workflow, not the access layer itself.
Autonomous operational decisions **Speculative for generic enterprise use** The risk and control requirements change materially once the system can change state; analytics evidence should not be used to justify autonomous execution.
A particularly important counterweight to optimistic text-to-SQL demos is Spider 2.0. Its enterprise tasks involve databases that can contain more than a thousand columns and require schema understanding, metadata, dialect documentation, project code and often complex multi-query SQL. The benchmark's sharp performance drop relative to older text-to-SQL benchmarks is evidence that “the LLM knows SQL” is not equivalent to “the LLM understands the enterprise.” [2](https://arxiv.org/abs/2411.07763) ### Different consumers require different readiness **Deliverable — Use-case differentiation**
AI consumer Primary job Semantic requirement Access requirement Evaluation requirement Recommended default boundary
**Internal Q&A** Find factual answers Low–medium; definitions for important terms User-level read access Citation/source correctness Curated search/data tools
**Conversational analytics** Answer KPI and slice/dice questions **High for KPIs, joins and time logic** Read-only curated analytical scope Golden questions + expected results Curated views + semantic definitions
**AI analyst** Explore hypotheses, run multiple queries Medium–high but needs more flexibility Wider read-only domain Multi-step correctness, provenance, cost Read-only analytical workspace
**Coding/data-engineering assistant** Understand/create pipelines and code Code, schema, lineage more important than KPI layer Repo + dev/test data; production tightly controlled Code/test/build evaluation Dev tools and non-prod environments
**Customer-facing assistant** Answer a customer's data questions Narrow but extremely precise **Hard tenant/user isolation** Disclosure tests + answer correctness Domain API or strongly isolated views
**Workflow agent** Use data to prepare/propose business work Domain-specific business state semantics Read plus constrained tools End-to-end workflow tests Typed APIs/tools
**Autonomous operational agent** Change business state Very high for decision inputs and action semantics Least-privilege write capabilities Safety, rollback, policy, outcome monitoring Transactional tools, never arbitrary warehouse write by default
Databricks' documented analytical agent design is read-only even while it performs multi-step reasoning and multiple SQL queries. PAR similarly restricts model visibility to prefiltered analytical data. These are design signals that **analytical autonomy and write autonomy need not—and should not automatically—be coupled**. [6](https://docs.databricks.com/aws/en/genie-agents/concepts) **Can one platform design safely support all seven?** Shared primitives can: identity, authorization policy, audit logs, metadata, data products, freshness signals and evaluation infrastructure. The **same interface and permission envelope should not**. Customer-facing multi-tenant analytics and autonomous operational actions have materially different failure consequences from an internal analyst's read-only exploratory session. PAR's architecture demonstrates the former distinction; OAuth and Zero Trust standards likewise favor resource- and action-specific privileges rather than broad ambient authority. [7](https://www.rfc-editor.org/rfc/rfc9700.html) ## Foundation, semantics, quality and metadata ### The minimum platform foundation **Deliverable — Minimum platform foundation** For a **bounded read-only AI analytics use case**, the genuinely necessary foundation is smaller than “enterprise data maturity”: - **An identifiable trustworthy source set.** The agent must know which tables/views/data products it may use, their grain and enough relationship information to avoid obvious analytical errors. Spider 2.0 and OpenAI's production report both show that schema alone is frequently insufficient in real enterprise analysis. [2](https://arxiv.org/abs/2411.07763) - **Deterministic authorization.** Access must be enforced by the database/API/policy layer rather than requested from the model in natural language. PAR's production design is direct evidence for this pattern; NIST Zero Trust is aligned with resource-specific policy enforcement. [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/) - **Definitions for the concepts that the use case actually asks about.** Not every enterprise term needs modeling. Critical metrics, dimensions, time semantics, exceptional filters and permissible joins do. - **Visible freshness and known failure state.** The AI should be able to distinguish “current and healthy” from “late, incomplete or unknown.” OpenAI specifically incorporates refresh/update information and can inspect live runtime state when stored context is stale. [3](https://openai.com/index/inside-our-in-house-data-agent/) - **A named owner/escalation path.** Someone must be able to decide whether an ambiguous definition or bad answer represents a data defect, semantic defect or agent defect. - **Traceability.** The user/operator should be able to recover the source, generated query/tool calls and result underlying a material answer. OpenAI's internal implementation links analyses to underlying results for verification. [3](https://openai.com/index/inside-our-in-house-data-agent/) - **A known-case evaluation set.** Both Snowflake and OpenAI describe question-to-expected-query/result evaluation as an ongoing regression control rather than a one-off launch test. [4](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst-evaluations) That is deliberately **not** a requirement for perfect enterprise-wide lineage, documentation of every table, a company ontology, 100% metadata coverage, or a single canonical definition for every disputed concept. Those may become justified later; requiring them before a contained pilot would make the experiment incapable of telling leadership which missing foundations actually matter. ### Semantic-investment options **Deliverable — Semantic-investment options** Semantic investment should be matched to the type of ambiguity being removed.
Investment Agent problem it solves Ongoing maintenance Strong trigger to invest Weak justification
**Business glossary** “What does ARR/churn/active/etc. mean?” Low–medium Terminology itself is disputed or opaque Agent mostly uses technical operational fields
**Metric definitions / metric store** Consistent numerator, denominator, filters, time windows Medium Repeated KPI questions across BI + AI consumers Mostly open-ended detailed analysis
**Semantic layer** Reusable entities, relationships, measures, dimensions, joins Medium–high Many questions repeatedly fail due to the same joins/metric logic One narrow domain with a handful of stable SQL queries
**Curated data products/views** Reduces raw schema search space and encodes grain/business logic Medium Existing analytics models are already trustworthy Assumption that agents need a new abstraction simply because they are agents
**Ontology** Formal vocabulary, entity types and relationships across heterogeneous domains High Cross-domain reasoning depends on explicit conceptual relationships Basic KPI analytics
**Knowledge graph** Traverse explicit entity relationships and attach heterogeneous context High Graph relations are themselves central to the use case Conventional dimensional warehouse questions
Current product engineering supports the narrower interpretation of semantic value. Snowflake's semantic-view evaluation explicitly uses natural-language questions paired with verified SQL as ground truth and measures generated results against them. Databricks documents the use of names, descriptions, relationships, SQL expressions, examples and verified/trusted query logic to improve analytical interpretation. These are **provider-design evidence that explicit semantics are useful inputs**, not evidence that every organization should purchase a separate semantic product. [4](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst-evaluations) A semantic layer earns its maintenance cost when the organization is repeatedly paying the same semantic tax: multiple agents, BI tools and analysts independently reconstruct identical metrics, joins and business rules. The reverse also holds. For twenty stable questions over five curated views, a semantic platform can easily be more machinery than the problem warrants. A useful decision test is: > **How many recurring agent failures would disappear if this semantic asset existed, and how many human-hours will it take every month to keep that asset correct?** Do not count theoretical reuse. Count observed failure classes. ### Data quality and freshness investment **Deliverable — Data-quality / freshness investments** AI changes the **exposure** side of data-quality economics more reliably than it changes the underlying probability that source data is wrong. A useful model is: **Expected defect cost ≈ defect probability × probability the AI consumes it × number of affected AI-mediated decisions/answers × consequence per affected use** An assistant that makes data accessible to ten times as many people or runs unattended analyses can increase the third term. It does not automatically make the source defect more likely. Therefore, “AI means we need to test every table” is poor economics; “AI increases the value of testing the small set of products it repeatedly consumes” is much more defensible.
Investment AI-specific business case Priority
**Freshness monitoring** Lets the agent distinguish healthy current data from late pipelines before presenting an answer **High for time-sensitive use cases**
**Automated quality tests** Prevent known structural/logic defects from silently propagating through repeated automated consumption High on exposed critical data
**Schema/data contracts** Prevent upstream changes from invalidating machine assumptions without notice High when many producers change independently
**Anomaly detection** Helps with unknown data shifts, but false positives and triage create operational cost Selective
**Ownership** Makes detected failures resolvable rather than merely observable **Foundational**
**Enterprise-wide blanket testing** Adds cost regardless of whether AI consumes the asset Low unless justified for other reasons
OpenAI's internal system retrieves pipeline-derived information including update behavior, grain and construction logic, while Snowflake's evaluation tooling treats regressions as something to detect continuously rather than assuming once-correct behavior remains correct. These support targeted observability around AI-consumed data, not blanket testing of the entire estate. [3](https://openai.com/index/inside-our-in-house-data-agent/) ### Metadata and catalog investment **Deliverable — Metadata / catalog investment** The highest-value metadata for an analytical agent is not necessarily the metadata that makes a catalog look complete. **Tier A — directly answer-affecting**
Metadata Why an agent needs it
Grain / uniqueness Prevents duplicate counts and aggregation mistakes
Business meaning of table/field Distinguishes technically similar datasets
Allowed/normal relationships and join keys Reduces invalid joins
Metric formulas, filters and time semantics Resolves business ambiguity
Caveats/exceptions Prevents generic interpretation from overriding company-specific logic
Freshness/update state Allows stale-data detection
Sensitivity/access classification Helps route to the appropriate tool/data boundary
**Tier B — discovery/debugging**
Metadata Primary value
Lineage Explain construction; diagnose changes and downstream impact
Ownership Escalation and maintenance
Usage/query history Shows which tables and joins practitioners actually use
Examples / verified queries Gives concrete interpretation of business questions
Pipeline/code links Reveals transformations and assumptions not visible in schema
OpenAI's deployed internal design uses almost exactly this mixture: schemas and lineage, query history, human descriptions and caveats, code-derived table meaning, refresh/granularity context, institutional knowledge and saved corrections. It explicitly states that schema/history alone do not capture all table meaning. [3](https://openai.com/index/inside-our-in-house-data-agent/) The significant caveat is **metadata accuracy**. A beautiful description that is six months wrong can be worse for an agent than no description because it creates machine-readable false confidence. Consequently, the economic unit should not be “percentage of columns documented.” Prefer measurements such as: **agent-exposed assets with current grain + owner + freshness + critical semantic definition**, and
**high-frequency questions covered by verified semantics/examples**. In the primary evidence reviewed, there is no convincing controlled enterprise study assigning a universal ROI to descriptions versus lineage versus tags versus usage history individually. Treat vendor claims of broad “metadata intelligence” as a hypothesis until your pilot attributes failures to missing metadata. ## Access architecture, permissions and actions ### AI access architecture options **Deliverable — AI access architecture options** The following ratings are decision guidance, not vendor performance measurements.
Access model Flexibility Governance / security Implementation Maintenance Auditability Best fit
**Unrestricted warehouse query** Very high Low Low Low initially Medium Expert sandbox
**Curated warehouse role/views** High High Low–medium Low–medium High **Internal analytics default**
**Semantic API** Medium High Medium Medium–high High Repeated KPI/conversational analytics
**Domain-specific tools/API** Low–medium **Very high** Medium–high Medium **Very high** Customer-facing/workflow/action
**Preapproved queries/templates** Low **Very high** Low Low Very high Small stable question set
**Read-only data product** Medium–high High Medium Medium High Domain analytics / portable boundary
The choice is fundamentally between letting the model decide **more of the query surface** and moving more decisions into deterministic software. PAR is instructive: the LLM does not see raw underlying tenant tables. Server-side code first constructs the user's authorized sandbox; the model sees only the resulting schema and generates analytical SQL within that boundary. Ambiguous questions are rejected or clarified before SQL generation. [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/) Databricks illustrates another viable point in the design space: multi-step analytical behavior can still generate only read-only SQL. [6](https://docs.databricks.com/aws/en/genie-agents/concepts) This suggests a useful architecture principle: > **Give the model freedom inside a boundary; do not ask the model to define the boundary.** ### Core platform versus AI access layer **Deliverable — Core platform versus AI access layer** **Prefer an AI-facing layer over the existing core when:** - the warehouse/lakehouse already contains sufficiently reliable domain data; - existing IAM or row/object policies are enforceable programmatically; - most observed gaps are discovery, context, semantics, interface shape or AI evaluation; - only one or a few domains are being exposed; - the organization wants to retain BI and analyst workflows unchanged. OpenAI describes its agent explicitly as an interface layer inheriting existing data permissions, while enriching context around the underlying platform. [3](https://openai.com/index/inside-our-in-house-data-agent/) **Fix the core platform when:** - no trustworthy representation of business grain exists; - the same KPI has irreconcilable implementations and nobody owns the resolution; - source identifiers cannot support safe joins; - permissions cannot deterministically express who may see which rows/entities; - freshness/quality failure is widespread upstream rather than agent-specific; - multi-tenant/customer isolation cannot be guaranteed without rebuilding data boundaries; - every AI application must independently recreate identical correction logic. That distinction prevents an architectural anti-pattern: hiding fundamentally broken data behind an increasingly elaborate agent layer. A useful test is: > Remove the LLM. Would this defect still harm a new analyst, dashboard, API or downstream data product? If yes, it is probably core data-platform debt. Fixing it only in the AI adapter creates another semantic silo. ### Permission and governance model **Deliverable — Permission / governance model** Existing IAM can be sufficient—but only when the AI layer can **faithfully propagate and enforce it**. OpenAI reports pass-through behavior in which users may query only tables they were already entitled to query; PAR demonstrates the harder multi-tenant case, where application identity is translated into deterministic row-level isolation before the model sees the data. These examples show two architectures rather than one universal IAM answer. [3](https://openai.com/index/inside-our-in-house-data-agent/) **For user-initiated assistants:** prefer delegated identity—“agent X acting on behalf of user Y”—over a shared highly privileged service principal wherever the underlying systems support it. OAuth 2.0 is specifically designed for limited delegated access, and RFC 8693 defines token-exchange semantics that can represent both the primary subject and the delegated actor. [8](https://www.rfc-editor.org/info/rfc6749/) **For unattended agents:** use a separately identifiable workload/agent identity with purpose-specific privileges. Current OAuth security best practice recommends restricting tokens to the minimum privileges required and, where possible, to particular resource servers, resources and actions. [9](https://www.rfc-editor.org/rfc/rfc9700.html) For audit purposes, the useful event is therefore not merely: `service-account queried customer_table` but conceptually: `human/workload subject → AI actor → tool → operation → resource → authorization decision → result` MCP can standardize the tool connection and schemas around tools, but it does **not eliminate the need for authorization policy or business semantics**. Its specification treats arbitrary data access/tool execution as requiring explicit security, consent and privacy consideration, and its architecture separates hosts, clients and servers to preserve security boundaries. [10](https://modelcontextprotocol.io/specification/draft) For sensitive categories, the access decision should tighten:
Data class Additional question before exposure
Employee data Is every exposed field necessary for this use and permitted for this user/purpose?
Customer personal data Is the purpose defined, minimization applied, retention understood, and output itself protected?
Financial data Are definitions, close/status timing, approval boundaries and materiality known?
Confidential commercial data Can sharing boundaries be expressed deterministically, including subsidiaries/teams/partners?
Multi-tenant/client data Can another tenant's rows be made **structurally unavailable**, not merely discouraged by instructions?
For organizations subject to GDPR, those choices interact with statutory principles including purpose limitation, data minimization and accuracy, and with data-protection-by-design and security obligations; introducing an AI interface does not waive those requirements. [11](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) The EU AI Act should not be treated as though every internal analytics assistant is automatically a “high-risk AI system.” Where a use case **does** fall into the Act's high-risk regime, the current consolidated text includes requirements around logging and human oversight and obligations for deployers. The Regulation was amended in 2026, so decisions should use the consolidated July 27, 2026 text rather than relying on the original 2024 text alone. [12](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng) ### The read-versus-action boundary **Deliverable — Read versus action boundary** Leadership should treat these as four different products:
Stage Meaning Additional controls required before advancing
**Read** Fetch/analyze information Data authorization, source trace, freshness, query/tool audit
**Recommend** Interpret data and advise a person Evidence, assumptions, uncertainty/ambiguity handling, human judgment
**Propose action** Form a concrete change but do not execute it Policy validation, target/delta preview, dry run, approver context
**Execute action** Change business state Action authorization, constrained transactional tool, approval/policy gate, idempotency, limits, recovery/compensation, kill switch, complete audit
The jump from read to execute is **not an incremental version of conversational analytics**. It changes the loss function. For execution, the agent should normally receive a specific capability such as: `issue_refund(customer, transaction, amount <= authorized_limit)` rather than: `run arbitrary SQL UPDATE` That makes resource, action and scope explicit and aligns with IETF guidance to restrict delegated access by resource and action. [13](https://www.rfc-editor.org/rfc/rfc9700.html) Before autonomous execution, leadership should demand answers to five operational questions: **Authorization:** Who—not merely which model—is authorized to cause this exact change? **Approval:** Which actions need a second human or deterministic policy decision? **Auditability:** Can the organization reconstruct identity, evidence, model/tool request, policy decision and resulting state? **Recovery:** Is the operation reversible, compensatable or safely retryable? **Blast radius:** What caps the number/value/scope/rate of changes when the agent is wrong? NIST's AI RMF and Generative AI Profile emphasize lifecycle risk management and evaluation rather than treating deployment as an endpoint; NIST's current metrology resources likewise frame field pilots, post-deployment feedback and continuous testing as part of trustworthy AI operation. [14](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) ## Operating model, portability and lifecycle economics ### Organizational ownership **Deliverable — Ownership / operating model** Most responsibilities are extensions of existing roles. Two responsibilities become materially more prominent: **agent/tool evaluation** and **AI-interface reliability**.
Asset/control Accountable owner Key collaborators
Business metric definition Business/domain owner Analytics/data
Curated domain data product Data/domain product owner Data engineering
Data quality/freshness Data-product owner Producer teams/platform
Metadata/lineage infrastructure Data platform Domain owners
AI-facing descriptions/examples Domain analytics/data product team AI team
Authorization primitives Security/IAM Data platform
Data access policies Business/data owner + security/privacy Platform
Agent tools/APIs Application/AI engineering Domain system owners
Golden evaluation cases Domain expert + AI/data team Business users
Agent regression/monitoring AI/application team Data platform
Privacy/regulatory constraints Privacy/legal/risk Security/data/business
Incident response Existing operational owner, extended to AI AI + data + security
The bad operating model is to appoint an “AI data owner” who somehow becomes responsible for definitions that the actual business domain refuses to own. AI does not resolve organizational ambiguity; it can automate its consequences. A useful separation is: - **Domain owns meaning.** - **Data platform owns reliable representation and common infrastructure.** - **Security owns enforceable authorization mechanisms.** - **AI/application team owns agent behavior, tool selection and evaluations.** - **Operational system owner owns write-side invariants.** OpenAI's case reinforces the cross-functional nature of this problem: its agent consumes human annotations, platform metadata, code, institutional knowledge and permissions rather than creating a parallel authoritative definition system solely inside the model. [3](https://openai.com/index/inside-our-in-house-data-agent/) ### Lock-in and portability **Deliverable — Lock-in and portability** Not all “agent-ready” investment has equal portability.
Asset Portability Reason
Business definitions in plain specification/code **High** Meaning can be re-expressed across systems
SQL transformations/views High–medium Widely understood, but dialect/platform behavior varies
Golden questions + expected results **High** Can evaluate replacement models/platforms
Data-quality rules Medium–high Logic portable; syntax/integration may not be
OAuth identity/delegation model **High** IETF-standardized authorization framework. [8](https://www.rfc-editor.org/info/rfc6749/)
MCP tool boundary Medium–high Open protocol reduces agent-framework coupling, but protocol compatibility/versioning still exists. [15](https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro)
Vendor-specific semantic DSL Medium–low Business logic is recoverable but representation/runtime is proprietary
Vendor catalog IDs/tags/lineage conventions Medium–low Migration requires remapping
Vendor-specific trusted-query/memory constructs Low–medium Closely tied to runtime implementation
Raw prompts describing business rules **Low** Hard to test, govern and migrate reliably
The most important portability move is therefore architectural rather than contractual: > **Keep canonical meaning and authorization policy upstream of the agent-specific adapter.** For example, “net revenue excludes refunds after settlement and uses invoice date” should not exist **only** in a proprietary agent prompt or vendor memory store. The vendor adapter may translate that rule into its semantic representation, but the company should retain an authoritative, testable version elsewhere. MCP deserves similar restraint. It is useful because it standardizes how AI clients discover/use external tools and context, but it is not a portable enterprise semantic layer and it does not automatically make authorization portable. Those are separate problems. [10](https://modelcontextprotocol.io/specification/draft) ### Lifecycle cost **Deliverable — Lifecycle cost** The correct economic comparison is not: > AI platform license versus no AI platform license. It is: > **Incremental lifetime cost of the controls required for the target use case versus measured lifetime value of enabling that use case.** A lifecycle cost model should include:
Cost bucket Typical driver
Platform/software Catalog, semantic, agent, observability or API products
Engineering Integration, context retrieval, policy enforcement, tooling
Semantic modeling Number of governed entities/metrics/relationships and rate of change
Metadata maintenance Number of exposed assets × change frequency × required human curation
Catalog maintenance Scanning, ownership, lineage mapping, taxonomy/classification
Data quality Tests, monitors, triage and defect remediation
IAM Identity propagation, role/policy engineering, access reviews
API/tool layer Tool contracts, validation, versioning, transactional safety
Evaluation Golden-set creation, adjudication, repeated model/query execution
Monitoring Logs, anomaly detection, security, latency/cost tracking
Support User questions, bad-answer triage, domain-owner time
Compute/model usage LLM/tool calls, warehouse scans, retries and evaluations
Evaluation is a real recurring workload, not free hygiene. Snowflake's current documentation notes that semantic evaluation incurs warehouse execution, judge-inference and storage costs and that nondeterministic SQL generation makes repeated runs useful for interpreting score variation. [4](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst-evaluations) The semantic-maintenance cost is likewise easy to underestimate. A definition is an operational dependency once an AI answer relies on it: changes to business rules, product taxonomy, account hierarchy or fiscal logic must make their way into both data and agent context. Leadership should require unit economics such as: **Cost per successful trusted task** [ \\frac{\\text{platform + compute + engineering + curation + evaluation + support}}{\\text{correct useful AI-mediated tasks}} ] **Maintenance intensity** [ \\frac{\\text{human hours spent maintaining semantics/metadata/evals}}{\\text{active domain or governed metrics}} ] **Avoided labor** [ (\\text{baseline analyst/user minutes} - \\text{AI-assisted minutes}) \\times \\text{successful task volume} ] **Expected risk reduction** [ (\\text{baseline defect/exposure probability} - \\text{controlled probability}) \\times \\text{loss exposure} ] None of these should be assigned a universal multiplier. Measure them in the pilot. ## Observable readiness and bounded experimentation ### Readiness without a readiness score **Deliverable — Observable readiness questions** Do not average these into “73% AI-ready.” A security failure and a missing column description are not commensurable. **Data and semantics** - Can we name the authoritative data assets for this use case? - Is their grain known? - Are critical join relationships known? - Are the key metrics and dimensions defined? - Are materially different definitions surfaced rather than silently collapsed? - Are exceptions and exclusion rules explicit? - Can the agent determine the relevant time zone, business calendar and time window? - Is current freshness visible? - Can the system recognize a failed or degraded data source? **Permissions** - Is authorization deterministic outside the model? - Can the agent obtain no more data than its human/workload subject is entitled to? - For customer/multi-tenant data, can another tenant's data be structurally excluded? - Is the actor and represented user/workload separately auditable? - Can privileges be revoked without changing prompts or redeploying a model? - Are tokens/credentials constrained by resource and action where technically feasible? Current OAuth security guidance recommends minimum necessary privilege and audience/resource restrictions. [13](https://www.rfc-editor.org/rfc/rfc9700.html) **Correctness and behavior** - Can a correct answer be traced to the executed query/tool result? - Does the agent clarify materially ambiguous questions? - Does it abstain or redirect unsupported questions? - Can it identify when the requested concept has no governed definition? - Does it distinguish “no rows” from “no access”? - Are known questions represented as regression cases? - Are generated results tested against known outcomes rather than only checking SQL syntax? - Are tests repeated enough to expose nondeterministic regressions? Snowflake and OpenAI both use curated expected queries/results as regression evidence. [4](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst-evaluations) **Operations** - Is there an owner for each exposed data product? - Is there an owner for each critical business definition? - Can a user report a bad answer and can the organization triage whether it was a data, semantic, access or agent failure? - Are model/tool/version changes evaluated before broad deployment? - Is query/model cost attributable to a use case? - Is there an incident path for inappropriate disclosure? **Actions, where relevant** - Is every write action exposed through an explicitly authorized operation? - Can the system preview the exact state change? - Is the operation idempotent or safely retryable? - Is recovery/compensation defined? - Is there a hard limit on value, count, scope or rate? - Can action capability be disabled immediately? ### Bounded pilot design **Deliverable — Pilot design** A good first experiment is **one domain, one AI consumer, read-only**. **Example:** internal sales conversational analytics. **Scope** Use the existing warehouse/lakehouse. Expose only a curated sales role/data product comprising the small set of customer/account/opportunity/order facts needed for the experiment. Add explicit definitions only for the metrics the pilot asks about. Do not build enterprise ontology, replace the catalog or remodel unrelated domains. **Consumer** A defined internal sales/revenue-operations user group asking natural-language analytical questions. **Interface** Read-only queries through the existing warehouse, curated role/views or existing semantic interface. Preserve user identity where feasible. Log source selection, generated SQL/tool calls, results and answer. **Suggested evaluation corpus** This is a proposed test design, not an industry standard:
Test family Example
Known questions “What was EMEA new ARR last quarter?”
Multi-step questions “Which segments drove the change, and which accounts explain most of it?”
Ambiguous questions “How is revenue doing?”
Conflicting definitions “Customers” where account/customer/company have different meanings
Invalid questions Request a metric the domain does not contain
Join traps Fact-to-fact or historical dimension edge case
Stale data Sales snapshot deliberately delayed
Pipeline degradation Critical source marked failed
Permission denial User asks for restricted compensation/customer-level field
Revoked permission Access removed after previous successful use
Changed definition Modify an approved KPI rule and test propagation
Prompt attack Ask the agent to ignore access policy or reveal hidden schema
Empty result Distinguish genuine zero from an error/access denial
PAR's system explicitly clarifies ambiguous/unsupported metrics before SQL generation; Snowflake and OpenAI both maintain curated question/expected-result evaluations. These production/provider patterns strongly support including ambiguity and regression cases rather than evaluating only happy-path SQL generation. [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/) **Pilot outcome measures** Do not lead with “users liked it.” Track: - **result correctness** against trusted outputs; - **clarification accuracy** for ambiguous questions; - **appropriate refusal/abstention** for unsupported questions; - **authorization test pass rate**, with any unauthorized disclosure treated as a release-blocking incident; - **stale/degraded-data recognition**; - **traceability completeness**; - **human task-completion time**, measured against the actual current workflow; - **number of analyst escalations avoided versus generated**; - **warehouse/model cost per successful task**; - **maintenance hours** spent adding definitions, examples and corrections; - **failure attribution**: data, semantic, metadata, access, model reasoning, tool, or UX. The most valuable pilot artifact is not the chatbot. It is the **failure distribution**. If 60% of wrong answers come from five undefined metrics, invest in semantics.
If they come from stale source tables, invest in quality/freshness.
If they come from schema search across 10,000 irrelevant objects, improve metadata/retrieval or reduce scope.
If permissions cannot be represented safely, redesign access.
If users mostly ask ten fixed questions, stop engineering a general AI analyst. ### Scale, redesign and stop conditions **Deliverable — Scale / redesign / stop conditions** **Scale the current design when:** - a bounded user group repeatedly completes valuable tasks; - known-question correctness is stable enough for the consequence of the use case; - ambiguity is handled through clarification/abstention rather than silent invention; - authorization tests show deterministic boundary enforcement; - new questions mostly require adding ordinary domain knowledge, not architectural exceptions; - maintenance/support cost stays below measured user/business value; - a second domain can adopt the pattern primarily through configuration and domain modeling rather than a bespoke rewrite. **Invest further in semantics when:** - the same metric/join/business-definition failures recur across users and AI tools; - corrections are duplicated in prompts, dashboards and agents; - domain owners repeatedly adjudicate definitions at query time; - verified questions demonstrate that explicit semantic modeling fixes a substantial share of failures. **Invest further in metadata/catalog when:** - the system frequently selects the wrong existing asset; - users/agents cannot distinguish similarly shaped datasets; - failures are attributable to unknown grain, lineage, ownership or freshness; - discovery cost dominates analytical reasoning. **Redesign upstream/core data products when:** - contradictions exist before the AI layer; - identifiers/grain/relationships are structurally unreliable; - freshness and data quality cannot be monitored at source; - authorization cannot be enforced without reproducing data into ad hoc AI silos; - multiple non-AI consumers exhibit the same failures. **Redesign the access architecture when:** - customer/tenant boundaries rely on model obedience; - agent credentials are broader than user/workload purpose; - audit cannot reconstruct who accessed what; - a customer-facing agent exposes raw warehouse discoverability that has no product reason to exist. **Stop—or replace AI with conventional software—when:** - users mostly ask a small stable set of questions; - a dashboard, search interface or parameterized query gives faster and more trustworthy results; - task frequency is too low to pay for semantic/evaluation/support overhead; - the agent creates as many analyst escalations as it removes; - the business cannot specify what a correct answer means; - write-side recovery or blast-radius controls cannot be made proportionate to the value of autonomous execution. ## Executive diligence questions and decision reversals ### Questions a CTO or Head of Data should answer before material investment **Deliverable — Questions a CTO / Head of Data should answer** **The business decision** - What user task becomes materially better if AI consumes company data directly? - What is the current cost/time/error rate of that task? - Is the desired capability retrieval, analytics, recommendation, or execution? - What is the consequence of a wrong answer, unauthorized answer or stale answer? - What evidence would cause us to decide that ordinary BI/search/software is better? **Scope** - Which domain is actually required? - How many datasets and metrics account for most expected usage? - Do users need arbitrary SQL flexibility or a bounded set of business operations? - Is this internal, employee-facing, customer-facing or multi-tenant? - Does the system need individual row-level data, or would aggregates suffice? **Existing platform** - Which failure modes already affect human analysts? - Are the authoritative sources actually known? - Are important joins, grain and exclusions encoded anywhere other than people's heads? - Can the existing warehouse/lakehouse expose a safe curated role or view? - Can current IAM be propagated into the AI request deterministically? - Can we obtain freshness/health state without building a new catalog? **Semantic investment** - Which specific questions fail today because a metric or relationship is ambiguous? - Would governed SQL/views or a small metric definition set solve those failures before we buy/build a universal semantic layer? - How frequently do definitions change, and who will maintain them? - Is cross-domain entity reasoning actually required strongly enough to justify ontology/knowledge-graph maintenance? **Security and governance** - Is policy enforced outside the model? - Can the agent be identified separately from the person/workload it represents? - Can access be revoked immediately? - Can we guarantee client/tenant isolation structurally? - What data reaches the model provider or agent runtime? - What logs exist for source access, generated query, tool calls and actions? **Operations** - Who decides that an AI answer is wrong? - How do they determine whether the cause is data, semantics, permissions or model behavior? - What regression set protects the important questions? - How much domain-expert time per month will semantics and evaluation consume? **Economics** - What use-case value must be achieved for the incremental platform expense to pay back? - What is cost per successful trusted task? - Which proposed platform components remain useful even if this particular model or agent product is replaced? - What is the cheapest reversible experiment that can falsify our assumptions? **Actions** - Why does the agent need write permission at all? - Can recommendation/proposal capture most of the value? - What exact operations would be exposed as tools? - What is the largest possible erroneous transaction/batch/change? - Can it be recovered? - Who carries liability when the system acts correctly according to its tool permissions but the business outcome is wrong? ### Decision reversals **Deliverable — Decision reversals: when the simpler conventional platform plus narrow AI interface wins** These cases should actively reverse a proposal for broad “agent-ready” transformation.
Situation Prefer Why
Users ask twenty stable KPI questions Existing warehouse + governed queries/metric endpoint + thin NL interface General-purpose semantic discovery adds little value
Strong curated marts already exist Read-only AI over those marts Do not recreate semantic logic simply because the consumer is an LLM
Customer-facing multi-tenant analytics Domain API or isolated authorized views Control and tenant isolation dominate arbitrary flexibility; PAR's production design follows this principle. [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/)
High-risk financial/HR decision support Narrow data products + recommend/propose mode Preserves human decision boundary and limits data/action surface
Sparse usage Manual analyst support or conventional BI Ongoing semantic/eval infrastructure may cost more than saved labor
Data definitions are politically unresolved Fix ownership/definition first No semantic technology can determine which disputed business policy leadership intends
Most failures are stale/broken pipelines Invest in core quality/freshness AI-facing metadata cannot make incorrect source data correct
Data is reliable but discovery is poor Improve focused descriptions/retrieval Core warehouse redesign is unnecessary
Definitions are stable but access is sensitive Curated roles/views + delegated identity IAM boundary has higher marginal value than semantic richness
Agent only needs three business actions Typed domain tools A general warehouse interface increases unnecessary attack and error surface
Existing BI already answers the job well Keep BI; add AI only for explanation/navigation if useful “Conversational” is not intrinsically higher value than a deterministic dashboard
Organization cannot operate regression tests or investigate bad answers Delay broad exposure AI consumption creates a system whose behavior cannot otherwise be reliably governed; current production designs emphasize continuous evaluations. [4](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst-evaluations)
The general reversal rule is: > **Use the narrowest interface that preserves the business value. Expand flexibility only when users demonstrably need it.** That principle is supported both by PAR's progression from unconstrained text-to-SQL toward constrained data sandboxes and by OpenAI's report that excessive tool overlap confused its internal agent, leading it to consolidate and restrict tools. [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/) ## Primary-source evidence register ### Claim-to-primary-source table **Deliverable — Claim-to-primary-source table**
Decision-relevant claim Primary source Evidence class What it establishes Important limitation
Real enterprise text-to-SQL is substantially harder than simplified benchmarks **Spider 2.0**, Lei et al. [2](https://arxiv.org/abs/2411.07763) Empirical benchmark Enterprise workflows require large-schema navigation, metadata/docs/code context and complex SQL Benchmark ≠ business production outcome
A direct LLM→warehouse design can be analytically promising yet unacceptable for multi-tenant security **PAR Technology / AWS engineering report** [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/) Production, self-reported PAR replaced its initial model-only access approach with deterministic layered controls Vendor-hosted case study, not independent audit
Deterministic data boundaries can be placed outside the LLM PAR/AWS [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/) Production architecture User identity creates a prefiltered sandbox before model-generated analytics Specific to PAR's architecture
PAR reports >50,000 production queries with zero cross-tenant exposure incidents PAR/AWS [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/) Production metric, self-reported Evidence that constrained architecture can operate at meaningful volume “Zero incidents” is company-reported
A data agent can be an interface layer over an existing platform/security model **OpenAI internal data-agent engineering report** [3](https://openai.com/index/inside-our-in-house-data-agent/) Production, self-reported Pass-through permissions and existing platform can be retained OpenAI's environment may not generalize
Rich context used in production extends beyond schema descriptions OpenAI [3](https://openai.com/index/inside-our-in-house-data-agent/) Production design Lineage, query history, annotations, code, institutional knowledge, memory and runtime state are used Does not causally quantify each field's marginal effect
AI analytical systems benefit from curated regression questions/results OpenAI [3](https://openai.com/index/inside-our-in-house-data-agent/) Production design Expected SQL/results are continuously tested No public external performance dataset
Semantic views can be evaluated against verified natural-language/SQL pairs **Snowflake documentation** [4](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst-evaluations) Provider design Explicit ground truth and regression tracking are built into production tooling Product documentation, not neutral outcome evidence
Natural-language→SQL generation remains nondeterministic under repeated evaluation Snowflake documentation [4](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst-evaluations) Provider design Same evaluation can generate different SQL; repeated tests are advised Product-specific implementation
Complex analytical agents can remain read-only **Databricks Genie documentation** [6](https://docs.databricks.com/aws/en/genie-agents/concepts) Provider design Multi-step analytical reasoning does not require writes Does not prove read-only is sufficient for every use case
Model prompts should not be treated as the authorization boundary PAR/AWS + NIST Zero Trust [1](https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/) Production + normative Deterministic policy enforcement should surround model behavior Exact implementation remains organization-specific
OAuth supports limited delegated access on behalf of a resource owner **RFC 6749** [8](https://www.rfc-editor.org/info/rfc6749/) Standards Standards-based delegated authorization model Application authorization logic still required
Subject and delegated actor can be represented separately in token exchange **RFC 8693** [16](https://www.rfc-editor.org/rfc/rfc8693) Standards Technical basis for user/agent identity propagation Support varies by IAM stack
Access tokens should be restricted to minimum necessary privilege/resources/actions **RFC 9700** [13](https://www.rfc-editor.org/rfc/rfc9700.html) Best Current Practice Supports purpose-limited agent credentials HTTP/OAuth scope; does not define enterprise data semantics
MCP standardizes connections/tools but has explicit security and consent concerns **MCP specification** [10](https://modelcontextprotocol.io/specification/draft) Protocol specification Useful portable tool/interface boundary Does not standardize business semantics or solve IAM
GDPR principles remain relevant to AI-mediated personal-data access **Regulation EU 2016/679** [11](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) Law Purpose/minimization/security obligations remain attached to processing Applicability depends on processing context
High-risk AI systems under EU law have logging/human-oversight/deployer obligations **Consolidated EU AI Act, July 27 2026** [12](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng) Law Risk class matters for system governance Most ordinary analytics assistants are not automatically high-risk
AI coding assistance can generate measurable productivity gains, but effects are task/context specific **Demirer et al., Management Science, 2026** [5](https://pubsonline.informs.org/doi/abs/10.1287/mnsc.2025.00535) Randomized field experiments 4,867 developers; pooled 26.08% increase in completed tasks Adjacent software-engineering evidence, not agent-ready-data ROI
AI risk should be evaluated throughout use/deployment, not only before launch **NIST AI RMF / GenAI Profile** [14](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) Normative Lifecycle evaluation and risk management are expected practices Voluntary framework, not performance evidence
### Evidence-based decision synthesis The evidence supports five relatively strong conclusions. **First: do not turn data-platform modernization into a prerequisite for experimentation.** Production examples show that useful AI analytics can be layered on top of existing warehouses and security systems. [3](https://openai.com/index/inside-our-in-house-data-agent/) **Second: do not equate that with “just give the LLM warehouse credentials.”** Real enterprise analytics requires context that humans currently supply implicitly, and sensitive access requires deterministic boundaries outside the model. [2](https://arxiv.org/abs/2411.07763) **Third: semantic investment should follow observed semantic failure.** Governed metrics, semantic layers and curated products have a clear mechanism for improving repeated KPI and join interpretation, and current provider systems explicitly use such information. The evidence reviewed does not justify an enterprise ontology or universal semantic platform simply because agents exist. [4](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst-evaluations) **Fourth: evaluation becomes part of the data interface.** When natural language and model reasoning sit between the user and SQL/tools, correctness is no longer characterized only by pipeline tests. Known business questions, ambiguity cases, access denial and regression behavior need to be tested at the agent level. [3](https://openai.com/index/inside-our-in-house-data-agent/) **Fifth: the read/action boundary is more consequential than the model choice.** Analytical agents can remain read-only while performing sophisticated multi-step analysis; execution introduces authorization, recovery and blast-radius requirements that belong to operational systems and security architecture, not to prompt engineering. [6](https://docs.databricks.com/aws/en/genie-agents/concepts) The resulting investment rule is intentionally conservative: > **Fund the smallest set of improvements that makes one valuable AI consumer trustworthy in one domain. Instrument the failures. Then invest in the layer where those failures originate.** That can legitimately result in a new semantic layer, stronger contracts, better metadata, an AI access service, or core-platform redesign. It can equally legitimately result in **none of them**—because a curated warehouse role, five governed metrics and a narrow read-only tool may be all the use case actually needs.