{"schema_version":"1.0","service":"Publicasta","type":"article","id":616,"slug":"openai_data_agent_governance_before_natural_language_analytics","title":"OpenAI’s Data Agent Makes Business Analytics Easier. The Hard Part Is Still Governance","excerpt":"OpenAI’s new Data agent puts plain-language analysis in front of company data. Its practical value will depend less on fluent answers than on metric definitions, permissions, evidence review, and a disciplined rollout.","language":"en","default_language":"en","canonical_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=en","image":{"url":"https://publicasta.com/storage/projects/8/pages/616/2026/09/491165c5-955b-4c43-abb1-119a860a95cc.webp","alt":"Abstract enterprise analytics dashboard with charts, metric definitions, permission controls, and an audit trail"},"publisher":{"id":8,"slug":"ai_practice","name":"AI Practice","url":"https://publicasta.com/ai_practice"},"author":{"name":"Anton R"},"published_at":"2026-09-15T10:39:36+00:00","updated_at":"2026-09-15T10:39:36+00:00","content_markdown":"OpenAI has introduced a Data agent in ChatGPT Work that lets employees ask questions of company data, investigate changes, build dashboards, and recommend or carry out follow-up actions in natural language. The announcement is significant because it moves an increasingly familiar AI promise into a less glamorous bottleneck: business analytics that is technically available but difficult for ordinary employees to use.\n\n ![Abstract enterprise analytics dashboard with charts, metric definitions, permission controls, and an audit trail](https://publicasta.com/storage/projects/8/pages/616/2026/09/491165c5-955b-4c43-abb1-119a860a95cc.webp)\n\n The product can connect to sources including Amazon Redshift, Datadog, Google BigQuery, ClickHouse, Databricks, MongoDB, and Snowflake. It can also use files and documents from Google Drive and SharePoint, work with business definitions supplied through semantic layers, and interact with tools such as Tableau, Power BI, Sigma, and ThoughtSpot. OpenAI says administrators choose which connections and roles are enabled, while queries enforce the connected account’s existing permissions. [OpenAI describes the product and its supported connections here](https://openai.com/index/put-data-to-work/).\n\n That sounds like a new interface for analytics. It is, but the more useful interpretation is narrower: the Data agent may reduce the cost of asking a first question. It does not remove the need to decide what the question means, whether the underlying data is fit for it, or how much authority an answer should have inside the business.\n\n For teams considering the product, the right starting point is not a collection of impressive prompts. It is a controlled pilot around one decision process, with named metrics, limited data access, independent checks, and a clear boundary between analysis and action.\n\n ## What OpenAI is actually adding\n\n Traditional business intelligence tools already support dashboards, SQL queries, scheduled reports, and governed metrics. The new layer is conversational investigation. A user can ask why weekly active users changed, compare periods, identify likely drivers, request a chart, ask for caveats, and turn the result into a shareable dashboard without learning the syntax of a warehouse or the structure of a BI application.\n\n OpenAI says the agent can use an organization’s business terms, metric definitions, custom calculations, and relationships between data sources. Those definitions can come from semantic layers and trusted systems such as dbt, Databricks Genie Ontology, GitHub, Snowflake Horizon, and existing BI dashboards. That detail matters. A natural-language question is only as reliable as the definitions available behind it.\n\n Consider the question: Why did gross retention fall last quarter? There are several plausible meanings of gross retention. The calculation may differ by product, customer segment, currency treatment, contract status, renewal window, and treatment of expansions or downgrades. A model can produce a polished explanation for the wrong definition. Connecting a semantic layer gives the agent a better chance of interpreting the question in the intended way, but it does not make the definition self-evident.\n\n The product also extends beyond a read-only answer. OpenAI says users can ask the agent to recommend next steps, identify people who should be involved, share findings through Slack or email, and carry out approved actions through connected tools. This is where the risk profile changes. A mistaken chart is a review problem. A mistaken message, ticket update, forecast adjustment, or workflow trigger can become an operational incident.\n\n The announcement presents the Data agent as available through ChatGPT Work’s Plugins directory. Administrators can install the Data plugin, enable relevant data-source plugins, manage access, and then let users start a conversation with @Data. The initial setup is therefore not just an employee choosing a chatbot. It is a workspace configuration decision involving data owners, identity administrators, security teams, and the people responsible for reporting definitions.\n\n ## The practical problem it could solve\n\n Many analytics requests are not hard because the SQL is complex. They are hard because the request must pass through several queues. A manager notices a change in conversion, asks an analyst for an explanation, waits for the analyst to find the relevant tables, clarifies the definition, waits again for a chart, and then discovers that a second team uses a different denominator. The delay can be longer than the analysis itself.\n\n A conversational agent can make the first pass cheaper. A sales manager might investigate pipeline movement before asking the revenue operations team for a formal report. A support leader could compare ticket volume with staffing and service-level data. A product team could explore a retention change and produce a list of hypotheses for the next experiment. Finance could use the tool to find anomalies in spending before deciding whether a deeper review is warranted.\n\n The value is not that every employee becomes a data scientist. The value is that more questions can be triaged close to the moment they arise. Easy questions may be answered directly. Ambiguous questions can be exposed earlier. Analysts can spend less time producing repetitive first drafts and more time validating definitions, designing measurements, and handling decisions that require judgment.\n\n OpenAI says that nearly all of its product team and more than two-thirds of its go-to-market organization use data agents in ChatGPT Work. It also names organizations in an alpha program, including NTT DATA, Thermo Fisher, ServiceTitan, Zipline, Empower, Piston, and others. Those examples are useful as signals of intended workflow, but they remain vendor-reported customer examples rather than independent evidence of general performance. A buyer should treat them as implementation references, not as a forecast of return on investment.\n\n A good pilot should measure less dramatic outcomes: time from question to a checked first answer, the percentage of answers requiring correction, the number of duplicated reporting requests, adoption by the intended user group, query cost, and the number of times a user misunderstood a metric despite receiving a fluent explanation. Those measures reveal whether the agent improves the decision process rather than merely producing attractive artifacts.\n\n ## Why the semantic layer matters more than the prompt\n\n The phrase natural-language analytics can make the interface appear to be the main innovation. In practice, the data model behind the interface is more important. A semantic layer gives a system shared names, relationships, calculations, and rules. Without one, the agent is forced to infer business meaning from table names, column names, descriptions, sample values, and conversational context. That can work for exploration. It is a weak basis for recurring executive reporting.\n\n Before a pilot, a team should write down the definitions for the metrics it expects users to ask about. Each definition should include the source tables, time zone, time window, filters, inclusion and exclusion rules, treatment of refunds or cancellations, currency conversion, and the owner who can approve a change. The list does not need to cover the entire warehouse. It needs to cover the decision the pilot is intended to support.\n\n The team should also document which source wins when systems disagree. A CRM may contain an opportunity stage, the billing system may contain an invoice status, and a product database may contain actual usage. All three can be correct in their own contexts. The agent needs a rule for answering a specific business question, not merely access to all three.\n\n This is a useful division of labor:\n\n - The agent can translate a question into an investigation, retrieve relevant information, compare periods, draft a visualization, and identify possible drivers.\n- The data owner defines the metric, source priority, acceptable filters, and freshness requirement.\n- The analyst or domain expert tests the result, inspects the evidence, and decides whether it is sufficient for a business decision.\n- The decision owner determines what action follows and whether the evidence meets the organization’s standard.\n\n The agent can shorten the path between these people. It cannot legitimately take ownership of all four roles.\n\n ## Permissions are necessary, but they are not the whole control system\n\n OpenAI says enterprise administrators can select available connections and roles, and that queries enforce the permissions of the connected account, including table-, row-, and column-level restrictions. That is an important design requirement. An AI interface should not become a side door around the authorization model already protecting a warehouse.\n\n It is also not enough to hear that permissions are enforced. The implementation should be tested with representative identities. A pilot should include a user who can see a regional dataset but not another region, a user who can see aggregated compensation but not individual salaries, and a user who can view customer activity without seeing personal identifiers. The team should test both direct questions and indirect questions that might reveal restricted information through totals, comparisons, or repeated queries.\n\n Google’s BigQuery documentation illustrates why these tests matter. BigQuery supports project, dataset, and table access controls, as well as row-level and column-level security. Row-level policies filter which records a principal can see; column-level policies can restrict sensitive fields and can be combined with masking. Google also warns that poorly designed access patterns can expose information through side channels such as query behavior or timing. [The BigQuery documentation explains the interaction between row and column controls](https://docs.cloud.google.com/bigquery/docs/using-row-level-security-with-features).\n\n The lesson is broader than BigQuery. A model may not need to print a protected value to leak something about it. A prompt such as “Which employee in the small European team had the largest compensation increase?” can become sensitive even when the table does not expose a salary column directly. Aggregation thresholds, small groups, rare categories, and repeated comparisons need explicit treatment.\n\n The minimum permission review should answer five questions:\n\n 1. Which identities can invoke the agent?\n2. Which connections can each identity use?\n3. Does the source system apply the same row and column restrictions to agent-generated queries as it does to ordinary queries?\n4. What happens when the agent combines data from sources with different access rules?\n5. Which logs show the user, question, generated query or operation, data sources touched, result destination, and any action approved afterward?\n\n If the answer to the final question is vague, the pilot is not ready for sensitive data.\n\n ## Privacy claims need to be matched to the actual product and contract\n\n OpenAI’s business-data policy says that, by default, inputs and outputs from ChatGPT Enterprise, ChatGPT Business, ChatGPT Edu, ChatGPT for Healthcare, and the API platform are not used to train or improve its models. It also describes encryption in transit and at rest, role-based controls, retention options for qualifying organizations, and data-residency choices for eligible services. [OpenAI’s business data page lists those commitments and their scope](https://openai.com/business-data/).\n\n Those commitments address important questions, but they do not answer every question a data team should ask. The relevant review must cover the exact ChatGPT Work edition, connected plugins, data providers, retention configuration, support access, regional processing, export and deletion behavior, and the terms governing any partner service. A promise that the model is not trained on business data is not the same as a promise that no connected system stores query logs, copied extracts, dashboard artifacts, or action records.\n\n The Data agent’s architecture also introduces a data-location question. OpenAI says the product can connect to enterprise sources and, in the financial-services product announced the same day, describes built-in data from providers that is indexed and hosted on OpenAI infrastructure. That financial-services offering is a separate product, but it demonstrates why customers should distinguish between a connector that queries their system and a service that copies, indexes, caches, or enriches data elsewhere. [OpenAI’s financial-services announcement describes that distinction for its targeted offering](https://openai.com/index/introducing-chatgpt-financial-services/).\n\n A security review should request a data-flow diagram, not just a security summary. It should show the path of a prompt, generated query, retrieved rows, intermediate files, dashboard output, audit record, and any outbound message. It should identify which parts are handled by OpenAI, the warehouse, the BI tool, the connector, and the action system. The organization should know which component is responsible for deletion and which component is responsible for access enforcement at each stage.\n\n ## Evidence review is the difference between analysis and automation theater\n\n An answer that says sales fell because of weaker enterprise demand may be plausible and still be wrong. The useful question is: What data supports that claim, which comparison was made, what alternative explanations were checked, and what remains unknown?\n\n OpenAI says users can review the evidence behind findings and ask follow-up questions. That should become a required operating habit. A dashboard without a visible definition and source trail is not a finished analysis. It is a lead for further investigation.\n\n A practical review template can ask the agent to return:\n\n - the exact metric definition used;\n- the date range and comparison period;\n- the tables, views, documents, or dashboards consulted;\n- the filters and joins applied;\n- the number of records or groups involved;\n- data freshness and missing-data warnings;\n- the strongest evidence for each conclusion;\n- plausible alternative explanations;\n- checks that would disprove the leading explanation;\n- a recommended next step that does not assume the conclusion is true.\n\n This format is deliberately less entertaining than a confident narrative. It is easier to audit. It also teaches users that a generated explanation is a hypothesis supported by evidence, not an executive answer simply because it is written clearly.\n\n Teams should maintain a small evaluation set of real questions with known answers and known traps. The set might include a metric whose definition changed, a table with a delayed refresh, a duplicated customer record, a region with a permission restriction, and a question whose correct response is that the data is insufficient. Run the set before launch and after every material change to the semantic layer, connector, model, or permissions.\n\n The “insufficient evidence” case deserves special attention. A system that always produces a driver is more dangerous than one that sometimes stops. A useful agent should be able to say that the available data supports correlation but not causation, that a source is stale, that two systems disagree, or that the sample is too small to identify a reliable pattern.\n\n ## Costs are not only subscription costs\n\n OpenAI’s announcement does not present a universal public price for the Data agent. That makes it premature to calculate a simple per-user return. The cost model is likely to depend on the ChatGPT Work arrangement, model usage, connected systems, warehouse query charges, BI licenses, data-provider agreements, storage, and any action tooling. Prospective buyers should ask for pricing and usage limits specific to their workspace rather than infer them from consumer ChatGPT plans or from ordinary database costs.\n\n There are also operational costs that appear after launch. Queries that scan large tables can consume warehouse resources. A user who repeatedly asks for a dashboard refresh may create avoidable load. Natural-language exploration can multiply the number of requests because it feels cheap to ask follow-up questions. Some systems charge for data scanned, API calls, dashboard refreshes, or premium connectors.\n\n A responsible pilot should set budgets and observe them. Start with curated views or summary tables where possible. Add query timeouts and scan limits. Record cost by team and workflow. Make freshness explicit so users do not keep refreshing a source that only updates once a day. Decide whether an agent-generated dashboard should be allowed to refresh automatically or only on request.\n\n Cost control is also a data-model issue. A poorly modeled warehouse makes the agent pay repeatedly for work that could have been prepared once. A well-designed semantic layer, aggregate table, or governed view can improve speed, reliability, and expense at the same time.\n\n ## Where it should and should not be used first\n\n The best first use cases have a clear owner, moderate sensitivity, repeatable questions, and a human who can check the result quickly. Examples include investigating product adoption, preparing an internal operating review, finding reporting inconsistencies, exploring support demand, comparing campaign performance, and drafting a list of questions for an analyst.\n\n The first use case should not be the most politically important report in the company. Do not begin with compensation, regulated customer decisions, medical conclusions, credit decisions, legal determinations, or an automated workflow that changes records for many people. Those areas may eventually benefit from the same interface, but they require stronger controls, more formal validation, and a clear accountability structure.\n\n Small companies should not assume that a large warehouse is required. A compact business may gain value by connecting a trusted sales or support dataset and using the agent to answer a narrow operational question. It may also discover that its real problem is missing definitions rather than lack of analytics software. That is a useful outcome.\n\n Large companies should not assume that a broad rollout is automatically efficient. A global warehouse can contain years of exceptions, acquisitions, renamed products, duplicated pipelines, and teams that use the same term differently. The agent will make this ambiguity easier to access. It will not make the ambiguity disappear.\n\n Teams should probably skip the product for now if they cannot identify a source owner, cannot test permissions, have no audit path, or do not have anyone available to check results. In that situation, the agent may increase the speed at which the organization creates disagreement.\n\n ## A four-week pilot that produces useful evidence\n\n A sensible pilot can be completed in four stages. The calendar is less important than the gates between them.\n\n ### Week one: choose the decision, not the technology\n\n Select one recurring decision such as explaining weekly activation changes or preparing a support-capacity review. Name the user group, decision owner, data owner, analyst reviewer, acceptable response time, and maximum sensitivity. Write down the five to ten questions the team actually asks today. Include at least one question that should produce an uncertainty warning.\n\n Inventory the relevant sources and identify which system owns each field. Create a small glossary with metric definitions, freshness expectations, and known exclusions. If the team cannot agree on a definition, record the disagreement instead of asking the agent to resolve it.\n\n ### Week two: prepare views and permissions\n\n Prefer governed views or curated datasets over unrestricted access to an entire production warehouse. Separate exploratory data from systems that contain direct identifiers, credentials, health information, payroll details, or other high-risk fields. Create test accounts that represent the people who will use the pilot.\n\n Configure logging, retention, and budget alerts before users begin. Confirm whether connected tools keep copies of prompts, queries, files, dashboards, or results. Review the vendor and connector terms for the exact services in scope.\n\n ### Week three: test accuracy and failure behavior\n\n Run the evaluation set. Compare agent-generated results with an analyst’s independently produced answer. Track not only numerical accuracy but also definition accuracy, source selection, permission behavior, citation quality, freshness warnings, and the ability to refuse or qualify an answer.\n\n Ask users to try normal questions and adversarially simple questions. A request such as “show me the full customer list” may expose an access-policy problem faster than a complex analytical prompt. Test small groups and sensitive segments. Test a source that is stale. Test a metric with a recent definition change.\n\n ### Week four: measure workflow impact\n\n Let the intended users work on real, low-risk questions. Measure time to a checked answer, correction rate, analyst review time, warehouse cost, number of abandoned sessions, and whether users can explain the evidence behind their conclusions. Interview the analyst reviewers. They often reveal whether the agent reduced repetitive work or merely moved the cleanup downstream.\n\n Only after this stage should the team decide whether to expand data access, add action permissions, or connect more business units. Expansion should be tied to demonstrated controls, not to the number of interesting charts produced during the trial.\n\n ## The alternative is not always another AI product\n\n A company evaluating the Data agent should compare it with improvements that may be less visible but more durable. A metric catalog, a governed semantic layer, better warehouse models, a self-service BI training program, a well-designed set of dashboards, or an analyst-on-call process may solve the underlying problem more directly.\n\n In some teams, the correct sequence is to fix the data model first and add a conversational interface later. In others, the existing definitions are sound but buried behind specialist tools, making a natural-language layer genuinely useful. The distinction can be tested. Give users the same question through the existing BI interface and through the agent. If the agent is faster but less accurate, improve the definitions and retest. If it is both faster and accurate within the pilot boundary, expand carefully.\n\n The choice also depends on lock-in. A semantic layer that is portable across query engines and BI tools can preserve flexibility. A workflow that depends on proprietary connectors, model behavior, hidden transformation logic, or undocumented prompt conventions may become difficult to migrate. Keep metric definitions, evaluation cases, access rules, and dashboard specifications in systems the organization can inspect and maintain independently of the conversational interface.\n\n ## The decision for teams today\n\n OpenAI’s Data agent is most compelling as a front door to governed data, not as a replacement for data governance. It can make investigation accessible to people who know the business problem but do not know the warehouse schema. It can produce a useful first draft of analysis, expose follow-up questions, and turn a result into a shareable artifact. Those are meaningful improvements when reporting queues are long and definitions are already under control.\n\n Its main limitation is equally practical. A fluent answer can hide a weak metric, an incomplete join, stale data, an unauthorized inference, or an unsupported causal story. The more smoothly the system works, the more important it becomes to make evidence, permissions, and uncertainty visible.\n\n Teams should try it when they have a narrow decision process, trusted source data, clear definitions, testable permissions, and people responsible for review. They should delay it when the organization is hoping a chatbot will settle unresolved data ownership or compensate for missing controls.\n\n The useful question is not whether an employee can ask a database a question in ordinary language. That capability is now arriving in several forms. The useful question is whether the organization can make the answer traceable, appropriately scoped, affordable, and safe enough to influence a real decision. For the Data agent, that is the boundary between convenient analytics and dependable work.","available_translations":[{"language":"ar","title":"وكيل البيانات من OpenAI يسهّل تحليلات الأعمال، لكن الحوكمة تظلّ العقدة الأصعب","html_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=ar","markdown_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=ar","json_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/openai_data_agent_governance_before_natural_language_analytics?lang=ar"},{"language":"de","title":"OpenAIs Daten-Agent macht Business-Analysen leichter. Die schwierige Aufgabe bleibt Governance","html_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=de","markdown_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=de","json_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/openai_data_agent_governance_before_natural_language_analytics?lang=de"},{"language":"en","title":"OpenAI’s Data Agent Makes Business Analytics Easier. The Hard Part Is Still Governance","html_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=en","markdown_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=en","json_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/openai_data_agent_governance_before_natural_language_analytics?lang=en"},{"language":"es","title":"El agente de datos de OpenAI facilita la analítica empresarial. La parte difícil sigue siendo la gobernanza","html_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=es","markdown_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=es","json_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/openai_data_agent_governance_before_natural_language_analytics?lang=es"},{"language":"fr","title":"L’agent Data d’OpenAI simplifie l’analyse métier. Le vrai défi reste la gouvernance","html_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=fr","markdown_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=fr","json_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/openai_data_agent_governance_before_natural_language_analytics?lang=fr"},{"language":"pl","title":"Agent danych OpenAI upraszcza analitykę biznesową. Najtrudniejsze pozostaje zarządzanie","html_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=pl","markdown_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=pl","json_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/openai_data_agent_governance_before_natural_language_analytics?lang=pl"},{"language":"ru","title":"Агент данных OpenAI упрощает бизнес-аналитику. Но главное препятствие по-прежнему связано с управлением данными","html_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=ru","markdown_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=ru","json_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/openai_data_agent_governance_before_natural_language_analytics?lang=ru"},{"language":"zh","title":"OpenAI 的数据智能体让商业分析更容易，但最难的仍是治理","html_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=zh","markdown_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=zh","json_url":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/openai_data_agent_governance_before_natural_language_analytics?lang=zh"}],"_links":{"self":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=en","api":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/openai_data_agent_governance_before_natural_language_analytics?lang=en","html":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=en","canonical":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=en","markdown":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=en","json":"https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=en","channel":"https://publicasta.com/api/public/v1/channels/ai_practice","channel_articles":"https://publicasta.com/api/public/v1/channels/ai_practice/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}