What you will find in this article:
- Why the individual use of AI, on its own, doesn't translate into governance.
- The three layers that organize work: where it is produced, where it is recorded, and where it is executed.
- How to divide usage between teams without locking anyone out.
- What can and cannot be included in the conversation, and who approves what comes out of it.
- Notion as a source of corporate truth: what to register and how to name it.
- Best practices for development with Claude Code and Codex: repository instructions, permissions, review, and publishing.
- A one-page checklist for the company to evaluate itself.
- Where the Bytebio Enter: organizing usage or guiding teams
In almost every company, AI arrived through the back door. Someone opened an account, solved a task that would take an afternoon in twenty minutes, told a colleague, and soon half the team was using it. The productivity is real. What doesn't exist is the rest: nobody knows what data was pasted into which conversations, good analyses reside in personal histories, and the decision made with the help of AI left no trace beyond a phrase on WhatsApp.
Banning AI doesn't solve the problem, because prohibition only pushes its use out of sight. Releasing everything doesn't work either. The way forward is to separate what AI does well, which is production, from what the company needs to protect, which is what it has decided and accepted as truth, and give each thing its proper place.
This article proposes a simple design for this. The examples use Claude and Codex, both in day-to-day work and in development, but the design is valid for any assistant.
The problem isn't AI, it's the jobs that disappear.
When each person uses AI on their own, three things are repeated.
- Knowledge gets trapped in conversation. The analysis that turned out well, the approved text, the criteria the team agreed upon in ten messages: all of that exists only in the conversation history of the person who spoke. When that person goes on vacation or leaves the company, the work goes with them.
- The data is entered without any criteria. No one decided what can be included in a conversation. Everyone uses their own common sense, and one person's common sense is not company policy.
- The stock is left without an owner. When the assistant starts sending messages, editing records, or changing code, the question changes from what the assistant wrote to who authorized it.
None of the three is a flaw in the tool. They are organizational gaps, and organization is the company's job, not the AI vendor's.
Three layers, each with its own role.
The design we use separates the work into three layers, each with its own place and rule.
| Layer | Where does it happen? | What lives there? | The rule |
|---|---|---|---|
| To produce | Claude, Codex | Drafts, analysis, research, code | Nothing that matters stays only here. |
| Register | Notion | Decisions, final documents, analyses, and what the company considers to be true. | It's the source. What isn't here hasn't been decided. |
| Execute | CRM, ERP, repository, website | Where change becomes a reality for the customer. | Every action with an external effect goes through a person. |
The phrase that summarizes the design is short: what matters comes out of the conversation. When a result becomes a decision, document, or code, it is moved to the recording or execution layer, with author, date, and origin. The conversation can be deleted without loss, because what was valuable in it is already in a place that the company controls.
This has a positive practical consequence: the company becomes less dependent on a specific tool. If the team changes assistants tomorrow, or uses two at the same time, the knowledge remains in the same place. Regarding why the record needs to exist before AI comes into play, it's worth reading about documenting how not to be dependent.
Organize usage among the teams.
Giving everyone access and expecting them to organize themselves is the quickest way to avoid problems from the start. Some simple decisions can prevent this.
Context by area, not by person. Each team (sales, customer service, finance, development) gets a standard context: what the company does, the vocabulary, the tone, the rules that always apply. Without this, each person explains everything again and each receives a different result for the same question. The context is written once, saved in Notion, and pasted or connected wherever the tool allows.
Clear roles, and few of them. Four are enough to start: who uses the data; who maintains the context for each team; who approves connectors and access, generally the IT or security area; and who is responsible for personal data, generally the legal department or the data protection officer.
What is personal and what belongs to the company. Drafting and exploration are free. What becomes a deliverable for a client, an official document, or a decision becomes the property of the company and goes into the records.
A library of successful requests. A successful request is an asset. When someone creates a good analysis script or a good response model, it goes to a Notion page with an owner and date, instead of remaining in one person's memory.
This is a company account, not a personal account. Administrative features vary by plan. The Claude Enterprise plan page lists, for example, single sign-on (SSO), user provisioning, role-based access control, audit logs, and data retention controls. Before choosing, check what the plan your company is going to contract includes, for both Claude and Codex, in the official documentation for each. This list will answer the question IT will ask: who accessed what and when.
Data: what comes in, what doesn't come in, what goes out
Three rules cover most of the risk.
1. Classify the data into three levels: Open (can be used in any conversation), Internal (only accessible within the company account), and Restricted (sensitive personal data, health information, financial data, and credentials of any kind). Restricted data is either not accessible or is only accessible within an environment approved by the company. Credentials, passwords, and access keys are never accessible at any level. The legal basis and purpose of processing personal data under the LGPD (Brazilian General Data Protection Law) are a decision for the legal department, and classification is what makes this decision applicable in daily operations.
2. Connect with the fewest possible permissions. When the assistant connects to a system (CRM, calendar, drive, database), the rule is to start with read-only access, allow writing only where necessary, and review from time to time who has access to what. One connector per purpose, with an owner.
3. Humans approve actions that have an external effect. Sending a message, publishing, deleting, paying, changing customer information: the assistant proposes, the person confirms. When automation becomes recurrent and high-volume, like an agent serving a customer, control shifts from approval for each action to complete logging, versioning, and change approval. It's the difference between reviewing each response and reviewing the system that responds.
For the overall framework of AI governance and its pillars, see AI governance: success or failure.
The Notion as a source of truth
The second layer only works if it has form. Notion is what we use and recommend, but what matters is the design: a unique place, with rules for name, ownership, and validity.
What is recorded.
- Decisions: What was decided, why, by whom, when, and what alternatives were discarded. This is the page that will answer, six months from now, "why we did it this way".
- Final documents: The current version of a policy, proposal, manual, or roadmap. Drafts belong in Claude or the Codex; what matters stays here.
- Reviews: An analysis without a date and source becomes outdated without warning, requiring a question, source data, date, and conclusion.
- Relevant conversations: A database with one line per conversation that produced something, with a specific title, source tool, searchable summary, status, and a link to reopen. Not everything is saved, only what had an effect.
Minimum conventions. Title that states the subject, not "Conversation 12". Source: the tool and the date. Owner: one person, not a team. Status: draft, revised, current, or replaced. Revision date, so the page indicates when it is no longer considered reliable.
Validity and conflict. When two pages say different things, the team needs to know which one is valid. A written precedence rule (for example, management instruction comes before published policy, which comes before a proposal in progress) resolves most cases before they become a point of contention.
How AI gets involved in record keeping. When the tool connects to Notion via a connector, it reads and writes on the same pages the team uses. When it doesn't, the person takes the result there. In both cases, a person reviews it before the page becomes active: the assistant drafts, the company decides.
In itself Bytebio This is how it works. Conversations that produce something become a line in a Notion database, with a title, source, summary, status, and a link to reopen it, while institutional content comes from Notion pages treated as sources, with precedence given to those in case of conflict.
Development with Claude Code and Codex
In development, governance has an advantage: a culture of versioning, reviewing, and publishing already exists. The best practice is to get the assistant into this culture, not to circumvent it.
1. Instructions in the repository. Claude Code reads the file. CLAUDE.md at the beginning of each session, and the Codex reads the AGENTS.mdBoth are stored in the repository, versioned with the code and shared via Git, so the instruction applies to the entire team and changes with each revision, like everything else. This is where build and test commands, conventions, what should never be done, and where decisions are made go. The Claude Code documentation recommends short, concise files (under 200 lines): "run npm test "Before commit" works better than "test your changes". In Codex, files are read from the repository root to the working directory, with the closest files taking precedence, and the set is limited to 32 KiB by default.
A lean framework that serves both purposes:
# Instruções do projeto
## Comandos
- Testes: npm test
- Build: npm run build
## Regras
- Nunca publicar em produção sem autorização de uma pessoa.
- Segredos ficam fora do repositório.
- Decisões em docs/DECISOES.md, estado atual em docs/ESTADO.md.If the team uses both tools, a single file is sufficient: in recent versions, Claude Code reads the AGENTS.md when there is not CLAUDE.md, and accepts importing it with a line @AGENTS.md inside CLAUDE.md.
2. Instructions guide, configuration ensures. This is the distinction that is most often lost. According to the documentation itself, the Claude Code deals with... CLAUDE.md as context, not as an imposed configuration. What needs to be guaranteed, such as preventing an action or access to a file, goes in managed settingsThe organization distributes these instructions to the machines, and the client applies them independently of what the assistant decides, or they use hooks, which run at fixed times. Codex has its own version of this, with sandboxing and agent approvals. Rule of thumb: what "can never happen" isn't a phrase in the instruction file, it's a block.
3. Minimal permissions and an isolated environment. The assistant starts by reading and requests approval for any changes made. The secret remains outside the repository and out of the context of the conversation. Work is done in a separate branch, not the main one.
4. The same delivery flow as for humans. Branch, pull request, review, automated tests, merge. The assistant opens the pull request; it doesn't publish directly to the main branch. Publishing to production requires authorization from a person at that moment, and verification that the build and tests pass beforehand.
5. Project memory in the repository. Each session starts without remembering the previous one. A short state file, with what we are doing, where we left off, and what comes next, updated at the end of each step, allows any session, from any person or tool, to resume from the correct point. Claude Code also saves automatic notes, but these remain on the user's machine; what the team needs to know goes to the repository.
6. Multiple parallel sessions require queuing. With more than one session working on the same system, the risk shifts. We've seen it happen: two sessions publishing the same system, and one unintentionally undoing the other's correction. The solution is small and inexpensive: a panel or script that shows what is open, the integration order, and what is live, and the rule to integrate one change at a time.
7. An AI-generated app is not a system. An application built in an afternoon on a platform like Base44 proves the idea, but it only becomes a company tool when it gains profile-based permissions, volume support, integration, and an owner. This path is currently in the coding phase at the company.
One-page checklist
People and accounts
- The accounts belong to the company, with a designated administrator, and are not personal cards.
- Each team has an owner of the default context.
- There is a person who approves connectors and access points.
Data
- The three levels (open, internal, restricted) are written down and the team is aware of them.
- Credentials, passwords, and keys never enter into a conversation.
- Each connector has an owner and the least possible permissions.
- Every action with an external effect requires the approval of a person.
Register
- Decisions, final documents, and analyses are sent to Notion, along with the source, owner, status, and revision date.
- There is a written rule of precedence for when two sources diverge.
- The assistant drafts the information; someone else gives it the status of being in effect.
Development
- Each repository has its own instruction file, short and to the point.
- What cannot happen is in the configuration, not just in the instructions.
- Change comes through branching, review, and testing; publication requires authorization.
- There is a state file and, if there are multiple sessions, a queue.
Where to start
Don't start with the entire company. Choose a team and a routine where AI is already used, and design the entire process there.
- Define the registration location and the naming convention, owner, and status. Half a page is enough.
- Write the usage policy on one page: The three levels of data, what requires approval, and who approves it.
- During development, write the repository's instructions file and move the information that cannot fail to the configuration.
- Use it, and then revise it. What the team did to circumvent the rule shows where it was wrong. Adjust the rule, not the team.
Once one team's design works, the others copy it, making adjustments based on their own work.
How Bytebio can help
A Bytebio It's an engineering house of Ribeirão PretoSince 2009, the company has been putting AI, automation, and CRM into production within companies that depend on operations for revenue, and is responsible for what it builds. Intelligent OperationsWe help organize the use of Claude and Codex: the layer design, the record structure in Notion, the data rules, and, in development, the instruction file, permissions, and delivery flow. We also guide the teams so that the practice continues to work after the consultancy ends.
If AI is already being used in your company, but its output is still confined to personal conversations, talk to the BytebioWe start by talking about how work happens today and frankly say where it's worth organizing first.
