In short
A company's data policy says that the records of former customers must be anonymised after a set period. Months later, an AI agent that builds reactivation lists finds those records intact in a copy of the CRM that was left out of the routine, and suggests contacting people who should already have left the base. The rule existed and no system applied it. Closing that gap is the job of data governance. With agents, it runs through the Company Brain, the layer that knows the company: what data exists, where it lives, how it relates and who can see what.
Data governance is the set of roles, rules and processes that decides who owns each piece of data, how it is defined, who may access it, at what quality and for how long it is kept. Put simply, it is the agreement on who answers for each piece of information and how it may be used.
Data management does the day-to-day work, and governance sets the rules for that work and who may change them. In 2024, NIST, the United States standards institute, described governance as the organising logic through which authority and control are exercised over data management, a common basis for its privacy, cybersecurity and AI risk frameworks.
Reference models typically cover these seven fronts:
The script is usually the same. Owners are named, policies are written and the glossary is published. The systems keep working as before.
The cause is the distance between the rule and the point of use. The retention policy exists as a PDF, and the purge routine covers only the main database. The access matrix lives in a spreadsheet, and the review of ERP profiles happens once a year.
While data passed through people and reviewed reports, an analyst caught the deviation before the number reached the board.
With agents, the consumer of the data becomes a system. It queries CRM, ERP, helpdesk and documents in seconds, on behalf of different people throughout the day. Four consequences follow:
That is why data governance has to operate on the query path, at the point where the agent meets the data.
The Company Brain connects the sources once and organises them into a knowledge graph, a business ontology and a semantic layer, serving context to models over MCP, the open protocol that connects models to data sources. The pillars of data governance get enforcement points in that structure:
Retention follows the same path. A record anonymised in the source system drops out of the answers on the next query, and a copy outside the inventory stays out of the connected sources until its owner classifies it.
The architecture applies rules that someone has to decide. Retention periods, the definition of revenue and access to margin by customer are decisions for named owners and the committee.
There are technical prerequisites too. Inherited permissions depend on correct profiles at the source, and a profile that is too broad in the ERP stays too broad through the agent. Traceability shows where a wrong value came from, and fixing it is the owner's job, at the source.
Periodic review of access and definitions is still needed, now with the log of every query as its basis.
Governing all data before the first use case tends to produce the document on the shelf. The most effective starting point is a critical domain, such as customer data, which concentrates personal data, the interest of several areas and LGPD requirements.
For that domain, the company names the owner, settles the conflicting definitions, maps sources and copies, and defines access and retention. Those decisions go into the ontology and the permissions before the first agent, which starts out querying the data with the rules already applied. Each following domain reuses the structure and adds only its own owners and definitions.
