Home / Technical notes / AI and Data
AI and DataGenerative AI governance in mid-sized companies: usage policy, data, and vendors
Employees already use AI assistants, authorized or not. Lean governance, with a usage policy, data classification, and vendor review, addresses most of the risk without blocking the gains.
In almost every mid-sized company we visit, generative AI arrived before the policy. Someone in marketing uses an assistant to draft copy, legal tests contract summaries, sales pastes the proposal spreadsheet to ask for an analysis. None of this is necessarily bad. The problem is that nobody knows exactly which tools are in use, with which data, and under which contract terms.
Banning it rarely works. The tools are one click away in the browser and on the phone. The more effective path is to offer an authorized alternative and set clear rules for what is and is not allowed.
A framework sized for the company
In 2024 NIST published NIST AI 600-1, a profile of the AI Risk Management Framework specific to generative AI. It describes twelve categories of risk that are unique to or exacerbated by this technology, including confabulation (false answers presented confidently), data privacy, information security, and intellectual property, and suggests actions organized by the framework's four functions: govern, map, measure, and manage.
For those building applications on top of language models, the OWASP Top 10 for LLM Applications, 2025 version, is the most used technical reference. It includes risks such as prompt injection, sensitive information disclosure, supply chain vulnerabilities, improper output handling, and excessive agency granted to agents.
A mid-sized company does not need to implement all of this. It needs three pieces done well.
Piece 1: acceptable use policy
The policy should fit on two pages and answer practical questions. Which tools are authorized? With what type of account (corporate, with negotiated terms, or personal)? What data can be entered? Who reviews generated content before it leaves the company? What should someone do if they realize they entered something they should not have?
Two rules usually cover much of the risk. First: AI-generated content that goes to a customer, a government body, or publication is reviewed by a named person. Second: personal data about customers and employees, trade secrets, and third-party information under confidentiality do not go into tools without a corporate contract.
Piece 2: data classification applied to AI
The policy only works if people know how to classify what they have in hand. A four-level classification is enough for most companies.
| Level | Examples | Use in generative AI |
|---|---|---|
| Public | Website, catalog, marketing material | Allowed in authorized tools |
| Internal | Procedures, internal presentations without customer data | Allowed only in corporate accounts |
| Confidential | Commercial proposals, prices, unpublished financial data | Only in corporate tools with a no-training clause |
| Restricted | Sensitive personal data, industrial secrets, data under contractual confidentiality | Prohibited, except in a specifically approved project |
The LGPD, Brazil's data protection law, applies whenever personal data is involved. Entering customer data into an AI tool is a processing operation and needs a legal basis and a compatible purpose. When the vendor processes data outside Brazil, international transfer rules also apply. None of this prevents use; it requires that use be thought through.
Piece 3: vendor review
Most generative AI risk in mid-sized companies lies in the contract, not the model. Before authorizing a tool, check some objective points:
- Does the vendor use entered data to train models? Can this be disabled contractually?
- How long is data retained and where is it processed?
- Are usage logs available to the company's administrator?
- Does the contract set out responsibilities in case of a security incident?
- Does the tool allow centralized user management and immediate removal of access?
- If the tool connects to internal systems or takes actions, what permissions does it receive?
The last point deserves special attention. Assistants that read email, access shared folders, or carry out tasks in systems widen the attack surface. That is exactly the prompt injection and excessive agency scenario OWASP describes. The practical rule is to grant the least permission necessary and require human confirmation for irreversible actions.
Who looks after this
In mid-sized companies it makes no sense to create a new structure. A small group, with representatives from IT, legal or the data protection officer, and a business area that uses the tools, meeting monthly, is enough. The agenda is fixed: newly requested tools, incidents, and a policy review every six months. A simple inventory of use cases in production, with owner and risk rating, completes the minimum.
30-day checklist
- Survey which generative AI tools are already in use, without a punitive tone.
- Choose and contract at least one corporate alternative with reviewed terms.
- Publish the acceptable use policy in plain language.
- Communicate the data classification with examples from the company itself.
- Set up the governance group and its monthly agenda.
- Create the use case inventory with owner and risk level.
Well-designed governance speeds adoption, because it removes people's doubts about what is allowed. In our experience, usage goes up after the policy comes out, not down.
References
- NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. Gaithersburg: NIST, 2024.
- NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. Gaithersburg: NIST, 2023.
- OWASP FOUNDATION. OWASP Top 10 for Large Language Model Applications. Versão 2025. OWASP GenAI Security Project, 2024.
- BRASIL. Lei nº 13.709, de 14 de agosto de 2018. Lei Geral de Proteção de Dados Pessoais (LGPD).