La IA bajo política

En una empresa regulada, escribir código con IA trae preguntas que no son técnicas: qué proveedor, qué datos pueden salir hacia el modelo, cuánto se conserva, quién lo aprobó y cuánto cuesta. kbspec separa lo que se declara una vez de lo que se mide en cada requerimiento, y pone un tope donde el gasto no tiene a nadie mirando.

La política, declarada: `aplicaciones/IA.md`

La siembra kb init-docs y la llena el equipo una vez: son decisiones de la organización, no del framework, y kbspec no las adivina.

Ajuste	Qué declara
`proveedor` · `plan` · `contrato`	Quién presta el servicio, con qué plan y bajo qué acuerdo
`datos_entrenan_modelos`	Si el proveedor usa el código para entrenar (`no` / `sí`)
`residencia_datos`	Dónde se procesan los datos
`clasificacion_maxima` · `prohibido`	Lo más sensible que puede ir en un prompt, y lo que nunca sale
`rutas_vedadas`	Lo que el agente no lee, no busca ni escribe (opcional; ver abajo)
`mcp_en_copilot`	Si la organización habilitó los servidores MCP en Copilot, que no se ve desde la máquina
`retencion_meses`	Cuánto se conservan expedientes y bitácoras
`responsable` · `aprobada_por` · `revisada`	Quién responde, quién la aprobó y cuándo se revisó

Cuatro son el mínimo que un auditor pide por su nombre —proveedor, datos_entrenan_modelos, clasificacion_maxima y retencion_meses— y kb check avisa mientras falte alguno. Un <llenar> no cuenta como declarado.

kb configuracion fijar IA datos_entrenan_modelos "no"
kb configuracion verificar politica-ia --por "<nombre — área>"   # se niega si está incompleta

La aprobación la registra una persona; el agente no puede hacerlo por ella. El dossier de auditoría copia la política tal cual, para que quien revise dentro de dos años lea las reglas que regían cuando se escribió el código (ver El rastro de auditoría).

El modelo de cada fase, y el que corrió de verdad

Qué clase de modelo conviene en cada fase lo decide el equipo en MODELOS.md: está en Modelos por fase. Lo que pasó de verdad no se le pregunta al agente. Al cerrar cada fase, kbspec lee de la traza de Copilot qué modelo hizo el grueso del trabajo y lo firma en el rastro; el commit de cada tarea lo lleva en el trailer Kbspec-Modelo, y kb modelo --revisar avisa cuando una fase corrió con una clase por debajo de la recomendada.

Cuánto cuesta, y cuándo es mucho

El consumo se mide por requerimiento, por fase y por modelo, y se costea con las tarifas de PRECIOS.md; la portada del expediente lo muestra desde la fase 1. De dónde sale cada número está en Cómo mide kbspec.

Lo que faltaba era saber cuánto es mucho. kb presupuesto compara lo que lleva el requerimiento contra el percentil 75 de los ya entregados del mismo tamaño en el equipo —su propio consumo.jsonl, nunca una tabla ajena—, en total y por fase. Con menos de cinco de referencia no hay presupuesto: kbspec no inventa uno. kb estado lo muestra y kb tarea --iniciar avisa al 80 % y al 120 %.

Frenar lo decide el equipo, en la sección de presupuesto de MODELOS.md:

> **Presupuesto:** `exigir`

Con exigir, pasado el 120 % la tarea siguiente no arranca hasta que una persona lo autorice en su terminal, con un motivo y un tope de créditos más, que quedan en el rastro. De fábrica rige avisar, que no frena a nadie; apagado no lo calcula.

kb presupuesto                                         # el del requerimiento abierto, por fase
kb presupuesto autorizar --hasta 20 --motivo "…"       # la persona, pasado el tope

El lote sin supervisión, con autorización y tope

kb lote correr lanza un agente por tarea sin nadie mirando cada turno. No arranca sin kb lote autorizar --hasta <créditos>, que da una persona —escribiendo «aprobado lote <créditos>» en el chat— para ese plan: si cambia el alcance de una tarea, hay que autorizar de nuevo. Al llegar al tope, corta a todos los agentes. El recorrido completo está en Tareas en paralelo.

Lo que entra al expediente

El expediente lo lee todo el equipo y queda en git para siempre. kb insumo mira el contenido de cada archivo —no la extensión— antes de copiarlo a entradas/:

Busca números de tarjeta (pasan Luhn y tienen forma de tarjeta; las de prueba públicas no cuentan), cuentas IBAN (pasan el módulo 97) y secretos (los patrones de la compuerta de escritura).
Un texto con eso entra como copia enmascarada —[número de tarjeta ••••6467]— y el original no se copia. Un Word, Excel o PowerPoint con eso no entra: no se enmascara sin rehacerlo.
Un PDF o una imagen no se pueden revisar: entran, con un aviso.
Si son datos ficticios de prueba, una persona corre kb insumo <archivo> --sin-guarda, y queda en el rastro con la huella del archivo.

Y en cualquier fase, un secreto no llega a escribirse. Antes de que una herramienta del agente escriba un archivo, la compuerta busca claves privadas, tokens de GitHub, llaves de AWS, de OpenAI o Anthropic, de Slack o de Google, cadenas de conexión con contraseña y PAT de Azure DevOps. Bloquea en vez de avisar, y el aviso nunca trae el valor.

Lo que el agente no lee

Lo que el agente lee viaja al modelo. Las rutas vedadas se declaran en rutas_vedadas de IA.md (patrones separados por coma) y en un .kbignore por repositorio (una regla por línea, sintaxis de .gitignore); TI puede sumar las suyas desde la política de la máquina. Las fuentes se suman, y un ! de un repositorio no levanta lo que vedó la organización, ni uno de IA.md lo que vedó TI. Antes de cada herramienta, la compuerta niega leer, listar, buscar, escribir o usar la terminal sobre lo vedado: dice qué regla y de dónde sale, deja la negación en el rastro sin el contenido, y KB_SIN_COMPUERTA no la levanta. Las reglas las cambia una persona, no el agente. Se ven en kb check --seguridad, en kb contexto <APP> —antes de explorar— y en el dossier.

Lo que sale de la máquina

Por iniciativa propia, kbspec sale a internet para tres cosas, a lo sumo una vez por día, y ninguna manda datos del proyecto: las tarifas y la lista de modelos de Copilot, las novedades del framework (git fetch de su propia copia) y la última versión de Playwright en npm.

Variable	Qué apaga
`KB_SIN_RED=1`	Toda salida automática; se sigue con lo que ya hay
`KB_ACTUALIZAR_PRECIOS=0`	Solo las tarifas (`=1` las trae aunque esté `KB_SIN_RED`, salvo que la política de la máquina imponga `SinRed`)
`KB_CREDENCIAL_AZ=0` · `KB_CREDENCIAL_GIT=0`	Que kbspec pida un token a `az` o al llavero de git

Las credenciales del tablero van solo a hosts permitidos: el Azure DevOps de Microsoft y la propia máquina. Un Azure DevOps de la casa se declara en cada máquina, no en TABLERO.md, que puede editar cualquiera con acceso al repositorio de documentación, o la IA:

kb integracion hosts --agregar devops.miempresa.local

`kb check --seguridad`

Lo que un auditor pregunta de una máquina, en un comando. Arriba de todo, la política de la máquina: de dónde sale, qué impone y si la puede cambiar alguien que no es TI. Después, si hay escapes puestos (KB_SIN_COMPUERTA, o KB_PANEL y KB_MCP fuera de su proceso), con qué permisos están las credenciales en disco (una legible por otros usuarios es un error), a qué servidores irían, qué sale solo a internet, las rutas vedadas —cuántas reglas y de dónde—, adónde va el rastro si hay un SIEM declarado y con qué identidad firma esa máquina las aprobaciones. Nunca muestra un valor, sale con 1 si encuentra un error, y con --json entra en un pipeline.

La política de la máquina: la impone TI

Una variable de entorno la pone cualquiera en su perfil, y también la IA si tiene una terminal. En un banco, lo que no se puede apagar lo decide TI en la máquina, con las mismas herramientas con las que gestiona VS Code o el navegador: GPO o Intune en Windows, un perfil de MDM en macOS, /etc/kbspec/policy.json en Linux. kbspec la lee y nunca la escribe; las plantillas (ADMX/ADML, perfil de macOS, JSON) están en plantillas/politica/.

Ajuste	Qué impone
`CompuertasObligatorias`	`KB_SIN_COMPUERTA`, los topes de turnos y de bucle y `KB_HOY` dejan de apagar nada; cada intento queda en el rastro
`SinRed`	kbspec no sale a internet por su cuenta, y nadie lo destraba desde una variable
`HostsPermitidos`	Los únicos servidores de la casa que reciben una credencial; reemplaza lo que declaró cada máquina
`VersionMinima`	Por debajo, kbspec no trabaja: solo corren `kb version`, `kb check` y `kb update`
`RutasVedadas`	Lo que el agente no lee ni escribe, sumado a `IA.md` y al `.kbignore`, y sin excepción que lo levante
`TrasladoSinSalida`	Ningún requerimiento sale de la máquina en un paquete de `kb traslado`, diga lo que diga `CICLO.md`; importar sigue funcionando
`TrasladoSinEntradas`	Los paquetes de `kb traslado` salen sin los insumos de `entradas/`

Si está mal escrita, cierra. Una política que existe y no se puede leer no deja trabajar «sin política»: el juez le niega toda herramienta al agente con el motivo, y los comandos se niegan salvo los que sirven para arreglarla. Una clave que la versión instalada no conoce solo se avisa: puede ser de una versión posterior. kb check --politica dice dónde la buscó, qué leyó y qué la contradice. Sin MDM, KB_POLITICA_ARCHIVO sirve para probarla, y solo rige si no hay una del sistema: si pudiera ganarle, serviría para debilitarla.

El chat, como registro de uso

Cuando la extensión abre un chat nuevo al cerrar una tarea o una fase, exporta el anterior al expediente (a mano: kb chat registrar <export.json>): un resumen en evidencias/chats/ con la hora, el agente, el modelo, los tokens y los créditos de cada pedido, el JSON completo comprimido y un evento en el rastro. Ahí busca un auditor quién pidió qué y qué IA respondió. Un chat exportado sin pedidos no se guarda ni deja un evento vacío: si el trabajo pasó en otra sesión, el export sale vacío, y guardarlo solo ensuciaba el rastro.