Cómo utilizar Claude y Codex en su empresa sin perder la gobernanza.

Lo que encontrarás en este artículo:

• Por qué el uso individual de la IA, por sí solo, no se traduce en gobernanza.
• Las tres capas que organizan el trabajo: dónde se produce, dónde se registra y dónde se ejecuta.
• Cómo repartir el uso entre equipos sin excluir a nadie.
• Qué se puede y qué no se puede incluir en la conversación, y quién aprueba lo que surge de ella.
• La noción como fuente de verdad corporativa: qué registrar y cómo denominarla.
• Buenas prácticas para el desarrollo con Claude Code y Codex: instrucciones del repositorio, permisos, revisión y publicación.
• Una lista de verificación de una página para que la empresa se autoevalúe.
• Donde el Bytebio Introduzca: organización del uso o equipos de orientación

En casi todas las empresas, la IA se coló por la puerta trasera. Alguien abrió una cuenta, resolvió una tarea que normalmente llevaría una tarde en veinte minutos, se lo comentó a un compañero y, en poco tiempo, la mitad del equipo la estaba usando. La productividad es real. Lo que no existe es el resto: nadie sabe qué datos se insertaron en qué conversaciones, los buenos análisis se encuentran en los historiales personales y la decisión tomada con la ayuda de la IA no dejó rastro más allá de una frase en WhatsApp.

Prohibir la IA no resuelve el problema, porque la prohibición solo la oculta. Liberarla por completo tampoco funciona. La solución consiste en separar las fortalezas de la IA, como la productividad, de aquello que la empresa necesita proteger, es decir, lo que ha decidido y aceptado como verdad, y asignar a cada cosa el lugar que le corresponde.

Este artículo propone un diseño sencillo para ello. Los ejemplos utilizan a Claude y Codex, tanto en el trabajo diario como en el desarrollo, pero el diseño es válido para cualquier asistente.

El problema no es la IA, sino los puestos de trabajo que desaparecen.

Cuando cada persona utiliza la IA por su cuenta, se repiten tres cosas.

• El conocimiento queda atrapado en la conversación. El análisis exitoso, el texto aprobado, los criterios acordados por el equipo en diez mensajes: todo eso existe únicamente en el historial de conversaciones de la persona que habló. Cuando esa persona se va de vacaciones o deja la empresa, el trabajo se va con ella.
• Los datos se introducen sin ningún criterio. Nadie decide qué se puede incluir en una conversación. Cada uno usa su propio sentido común, y el sentido común de una persona no constituye la política de la empresa.
• Las acciones quedan sin propietario. Cuando el asistente comienza a enviar mensajes, editar registros o modificar el código, la pregunta cambia: ya no se trata de qué escribió el asistente, sino de quién lo autorizó.

Ninguno de los tres constituye un fallo de la herramienta. Se trata de deficiencias organizativas, y la organización es responsabilidad de la empresa, no del proveedor de IA.

Tres capas, cada una con su propia función.

El diseño que utilizamos divide el trabajo en tres capas, cada una con su propio lugar y regla.

La frase que resume el diseño es breve: lo importante surge de la conversación. Cuando un resultado se convierte en una decisión, documento o código, se traslada a la capa de grabación o ejecución, con autor, fecha y origen. La conversación se puede eliminar sin pérdida de información, ya que lo valioso que contenía ya se encuentra en un lugar controlado por la empresa.

Esto tiene una consecuencia práctica positiva: la empresa se vuelve menos dependiente de una herramienta específica. Si el equipo cambia de asistente mañana o usa dos a la vez, el conocimiento permanece en el mismo lugar. Respecto a por qué es necesario que exista el registro antes de que entre en juego la IA, vale la pena leer sobre cómo documentar la falta de dependencia.

Organizar el uso entre los equipos.

Dar acceso a todos y esperar que se organicen por su cuenta es la forma más rápida de evitar problemas desde el principio. Algunas decisiones sencillas pueden prevenirlo.

Contexto por área, no por persona. Cada equipo (ventas, atención al cliente, finanzas, desarrollo) recibe un contexto estándar: la actividad de la empresa, el vocabulario, el tono y las normas que se aplican siempre. Sin esto, cada persona tendría que explicarlo todo de nuevo y obtendría una respuesta diferente a la misma pregunta. El contexto se escribe una sola vez, se guarda en Notion y se puede pegar o conectar donde la herramienta lo permita.

Funciones claras y pocas. Cuatro son suficientes para empezar: quién utiliza los datos; quién mantiene el contexto para cada equipo; quién aprueba los conectores y el acceso, generalmente el departamento de TI o el de seguridad; y quién es responsable de los datos personales, generalmente el departamento legal o el responsable de protección de datos.

Lo que es personal y lo que pertenece a la empresa. La redacción y la exploración son gratuitas. Lo que se convierte en un entregable para un cliente, un documento oficial o una decisión pasa a ser propiedad de la empresa y se archiva.

Una biblioteca de solicitudes exitosas. Una solicitud exitosa es un activo. Cuando alguien crea un buen script de análisis o un buen modelo de respuesta, este se guarda en una página de Notion con un propietario y una fecha, en lugar de permanecer en la memoria de una sola persona.

Esta es una cuenta corporativa, no personal. Las funciones administrativas varían según el plan. La página del plan Claude Enterprise incluye, por ejemplo, inicio de sesión único (SSO), aprovisionamiento de usuarios, control de acceso basado en roles, registros de auditoría y controles de retención de datos. Antes de elegir, consulte la documentación oficial del plan que su empresa va a contratar, tanto para Claude como para Codex. Esta lista responderá a la pregunta que se hará el departamento de TI: quién accedió a qué y cuándo.

Datos: qué entra, qué no entra, qué sale

Tres reglas cubren la mayor parte del riesgo.

1. Clasifique los datos en tres niveles: Abiertos (pueden usarse en cualquier conversación), Internos (solo accesibles dentro de la cuenta de la empresa) y Restringidos (datos personales sensibles, información de salud, datos financieros y credenciales de cualquier tipo). Los datos restringidos no son accesibles o solo son accesibles dentro de un entorno aprobado por la empresa. Las credenciales, contraseñas y claves de acceso nunca son accesibles en ningún nivel. La base legal y la finalidad del tratamiento de datos personales según la LGPD (Ley General de Protección de Datos de Brasil) son una decisión del departamento legal, y la clasificación es lo que hace que esta decisión sea aplicable en las operaciones diarias.

2. Conéctate con la menor cantidad de permisos posible. Cuando el asistente se conecta a un sistema (CRM, calendario, unidad de almacenamiento, base de datos), la regla es comenzar con acceso de solo lectura, permitir la escritura solo cuando sea necesario y revisar periódicamente quién tiene acceso a qué. Un conector por propósito, con un propietario.

3. Los humanos aprueban acciones que tienen un efecto externo. Enviar un mensaje, publicar, eliminar, pagar, modificar la información del cliente: el asistente propone, la persona confirma. Cuando la automatización se vuelve recurrente y de alto volumen, como cuando un agente atiende a un cliente, el control pasa de la aprobación de cada acción al registro completo, el control de versiones y la aprobación de cambios. Es la diferencia entre revisar cada respuesta y revisar el sistema que responde.

Para conocer el marco general de la gobernanza de la IA y sus pilares, consulte Gobernanza de la IA: ¿éxito o fracaso?

La noción como fuente de verdad

La segunda capa solo funciona si tiene forma. Notion es la herramienta que usamos y recomendamos, pero lo que importa es el diseño: un espacio único, con reglas para el nombre, la propiedad y la validez.

Lo que se registra.

• Decisiones: ¿Qué se decidió, por qué, quién lo decidió, cuándo y qué alternativas se descartaron? Esta página responderá, dentro de seis meses, a la pregunta: "¿Por qué lo hicimos de esta manera?".
• Documentos finales: La versión actual de una política, propuesta, manual o plan de acción. Los borradores pertenecen a Claude o al Codex; lo importante se queda aquí.
• Reseñas: Un análisis sin fecha ni fuente queda obsoleto sin previo aviso, requiriendo una pregunta, datos de origen, fecha y conclusión.
• Conversaciones relevantes: Una base de datos con una línea por cada conversación que haya generado algún resultado, con un título específico, la herramienta de origen, un resumen consultable, el estado y un enlace para reabrirla. No se guarda todo, solo lo que tuvo repercusión.

Convenciones mínimas. Título que indique el tema, no «Conversación 12». Fuente: la herramienta y la fecha. Responsable: una persona, no un equipo. Estado: borrador, revisado, vigente o reemplazado. Fecha de revisión, para que la página indique cuándo deja de considerarse fiable.

Validez y conflicto. Cuando dos páginas contienen información contradictoria, el equipo necesita saber cuál es la válida. Una regla de precedencia escrita (por ejemplo, las instrucciones de la gerencia tienen prioridad sobre la política publicada, que a su vez tiene prioridad sobre una propuesta en proceso) resuelve la mayoría de los casos antes de que se conviertan en motivo de controversia.

Cómo interviene la IA en el registro de datos. Cuando la herramienta se conecta a Notion mediante un conector, lee y escribe en las mismas páginas que utiliza el equipo. Si no se conecta, la persona encargada de gestionar el resultado es quien lo hace. En ambos casos, una persona revisa el documento antes de que la página se active: el asistente redacta el borrador y la empresa decide.

En sí mismo Bytebio Así es como funciona. Las conversaciones que generan algo se convierten en una entrada de la base de datos de Notion, con un título, fuente, resumen, estado y un enlace para volver a abrirla, mientras que el contenido institucional proviene de las páginas de Notion tratadas como fuentes, dándose prioridad a estas últimas en caso de conflicto.

Desarrollo con Claude Code y Codex

En el desarrollo, la gobernanza tiene una ventaja: ya existe una cultura de control de versiones, revisión y publicación. La mejor práctica es integrar al asistente en esta cultura, no eludirla.

1. Instrucciones en el repositorio. Claude Code lee el archivo. CLAUDE.md al comienzo de cada sesión, y el Códice lee el AGENTS.mdAmbos se almacenan en el repositorio, versionados con el código y compartidos a través de Git, por lo que la instrucción se aplica a todo el equipo y cambia con cada revisión, como todo lo demás. Aquí es donde se almacenan los comandos de compilación y prueba, las convenciones, lo que nunca se debe hacer y donde se toman las decisiones. La documentación de Claude Code recomienda archivos cortos y concisos (menos de 200 líneas): "ejecutar npm test "Antes de confirmar" funciona mejor que "prueba tus cambios". En Codex, los archivos se leen desde la raíz del repositorio hasta el directorio de trabajo, priorizando los archivos más cercanos, y el conjunto está limitado a 32 KiB por defecto.

Un marco de trabajo ágil que cumple ambos propósitos:

# 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.

Si el equipo utiliza ambas herramientas, un solo archivo es suficiente: en versiones recientes, Claude Code lee el AGENTS.md cuando no hay CLAUDE.mdy acepta importarlo con una línea @AGENTS.md dentro del CLAUDE.md.

2. Guía de instrucciones, la configuración garantiza. Esta es la distinción que con mayor frecuencia se pierde. Según la propia documentación, el Código Claude trata sobre... CLAUDE.md como contexto, no como una configuración impuesta. Lo que necesita ser garantizado, como impedir una acción o el acceso a un archivo, va en configuración administradaLa organización distribuye estas instrucciones a las máquinas, y el cliente las aplica independientemente de lo que decida el asistente, o bien utiliza ganchos que se ejecutan en momentos fijos. Codex tiene su propia versión de esto, con entornos aislados y aprobaciones de agentes. Regla general: lo que "nunca puede suceder" no es una frase en el archivo de instrucciones, sino un bloque.

3. Permisos mínimos y un entorno aislado. El asistente comienza leyendo y solicita aprobación para cualquier cambio realizado. El secreto permanece fuera del repositorio y del contexto de la conversación. El trabajo se realiza en una rama separada, no en la principal.

4. El flujo de entrega es el mismo que para los humanos. Rama, solicitud de extracción, revisión, pruebas automatizadas, fusión. El asistente abre la solicitud de extracción; no publica directamente en la rama principal. La publicación en producción requiere autorización de una persona en ese momento y la verificación previa de que la compilación y las pruebas se hayan realizado correctamente.

5. Memoria del proyecto en el repositorio. Cada sesión comienza sin recordar la anterior. Un breve archivo de estado, que registra lo que estamos haciendo, dónde lo dejamos y qué sigue, actualizado al final de cada paso, permite que cualquier sesión, desde cualquier persona o herramienta, se reanude desde el punto correcto. Claude Code también guarda notas automáticas, pero estas permanecen en el equipo del usuario; la información que el equipo necesita se guarda en el repositorio.

6. Las sesiones paralelas requieren una cola de espera. Con más de una sesión trabajando en el mismo sistema, el riesgo se traslada. Lo hemos visto suceder: dos sesiones publicando el mismo sistema, y ​​una deshaciendo involuntariamente la corrección de la otra. La solución es sencilla y económica: un panel o script que muestre qué está abierto, el orden de integración y qué está activo, y la regla para integrar un cambio a la vez.

7. Una aplicación generada por IA no es un sistema. Una aplicación creada en una tarde en una plataforma como Base44 demuestra la idea, pero solo se convierte en una herramienta de la empresa cuando obtiene permisos basados ​​en perfiles, soporte para volumen, integración y un propietario. Este camino se encuentra actualmente en la fase de codificación en la empresa.

Lista de verificación de una página

Personas y cuentas

1. Las cuentas pertenecen a la empresa, con un administrador designado, y no son tarjetas personales.
2. Cada equipo tiene un responsable del contexto predeterminado.
3. Existe una persona que aprueba los conectores y los puntos de acceso.

Datos

4. Los tres niveles (abierto, interno, restringido) están documentados y el equipo los conoce.
5. Las credenciales, las contraseñas y las claves nunca se mencionan en una conversación.
6. Cada conector tiene un propietario y los permisos mínimos posibles.
7. Toda acción con un efecto externo requiere la aprobación de una persona.

Registro

8. Las decisiones, los documentos finales y los análisis se envían a Notion, junto con la fuente, el propietario, el estado y la fecha de revisión.
9. Existe una regla escrita de precedencia para cuando dos fuentes difieren.
10. El asistente redacta la información; otra persona le da el estatus de estar en vigor.

Desarrollo

11. Cada repositorio tiene su propio archivo de instrucciones, breve y conciso.
12. Lo que no puede ocurrir está en la configuración, no solo en las instrucciones.
13. El cambio se produce mediante la ramificación, la revisión y las pruebas; la publicación requiere autorización.
14. Existe un archivo de estado y, si hay varias sesiones, una cola.

Por dónde empezar

No empieces con toda la empresa. Elige un equipo y una rutina donde ya se utilice la IA, y diseña todo el proceso allí.

1. Defina la ubicación de registro y la convención de nomenclatura, el propietario y el estado. Media página es suficiente.
2. Redacte la política de uso en una sola página: Los tres niveles de datos, qué requiere aprobación y quién la aprueba.
3. Durante el desarrollo, escriba el archivo de instrucciones del repositorio y mueva la información que no puede fallar a la configuración.
4. Úsalo y luego revísalo. La forma en que el equipo eludió la regla demuestra dónde estuvo el error. Hay que modificar la regla, no al equipo.

Una vez que el diseño de un equipo funciona, los demás lo copian, haciendo ajustes en función de su propio trabajo.

¿Cómo puede ser Bytebio puede ayudar

A Bytebio Es una casa de ingeniería de Ribeirão PretoDesde 2009, la empresa ha estado implementando IA, automatización y CRM en empresas que dependen de las operaciones para generar ingresos, y es responsable de lo que desarrolla. Operaciones inteligentesAyudamos a organizar el uso de Claude y Codex: el diseño de capas, la estructura de registros en Notion, las reglas de datos y, durante el desarrollo, el archivo de instrucciones, los permisos y el flujo de entrega. También guiamos a los equipos para que la práctica siga funcionando una vez finalizada la consultoría.

Si la IA ya se utiliza en su empresa, pero su resultado aún se limita a conversaciones personales, habla al BytebioComenzamos hablando de cómo se trabaja hoy en día y decimos con franqueza dónde merece la pena organizarse primero.