Cómo escribir una política de uso de inteligencia artificial en la empresa

El problema no es si se aprueba la IA, es que el equipo ya la usa sin ningún control

Toda empresa que hoy discute si debe permitir la inteligencia artificial llega tarde a esa conversación. La IA generativa no entró por la puerta de sistemas ni pidió permiso a nadie: entró por el celular personal de cada persona, con una cuenta gratuita, sin contrato, sin acuerdo de confidencialidad y sin que nadie del área de seguridad se enterara. El vendedor que pega el correo completo de un cliente para que se lo resuma, el analista que sube una planilla con sueldos para que le arme un gráfico, el asistente que copia un contrato entero para que le explique una cláusula: nadie de ese grupo actúa de mala fe. Actúan porque la herramienta funciona, resuelve en minutos lo que antes tomaba horas, y nadie les dijo qué no se puede hacer con ella.

El costo real no aparece el día que alguien usa IA, aparece el día que algo sale mal y no hay manera de reconstruir qué pasó. Un cliente reclama que su información apareció en un lugar que no debía, y la empresa no puede responder qué herramienta se usó, con qué cuenta, ni qué datos entraron en ese prompt. No hay registro, no hay responsable, no hay ni siquiera una lista de quién usa qué. La política de uso de inteligencia artificial en la empresa no se escribe para frenar una adopción que ya pasó. Se escribe porque la empresa necesita poder responder esa pregunta la próxima vez que se la hagan.

Qué es una política de uso de inteligencia artificial en la empresa (y qué no es)

Una política de uso de inteligencia artificial no es un documento de visión ni un manifiesto sobre el futuro del trabajo. Tampoco es la estrategia de adopción de IA de la empresa, esa vive en otro documento, con otro dueño y otro horizonte. Es un documento operativo, parecido en espíritu a una política de seguridad de la información o a un manual de uso de dispositivos: corto, concreto, y pensado para que cualquier persona del equipo lo lea en diez minutos y sepa exactamente qué puede hacer y qué no.

La diferencia entre “prohibir” y “ordenar” el uso de IA no es cosmética, es la que determina si el documento sirve o queda de adorno. Prohibir una herramienta en la red corporativa no elimina su uso, lo empuja al celular personal, fuera de cualquier visibilidad de la empresa. Ordenarlo significa decirle al equipo qué herramienta usar, con qué cuenta, para qué tipo de trabajo y con qué información, de modo que el uso siga existiendo pero dentro de un canal que la empresa puede ver y sostener. Una empresa que de verdad quiere convertirse en una empresa AI Native no lo logra bloqueando herramientas: lo logra ordenando su uso desde el primer día.

Los siete puntos que tiene que tener sí o sí

No hace falta un documento de cuarenta páginas para que esto funcione. Hace falta que cubra estos siete puntos, sin saltarse ninguno:

• Alcance: a quién aplica la política. No solo a la nómina fija: cubre también a colaboradores externos, agencias y freelance que tocan información de la empresa, porque un dato sensible no distingue el tipo de contrato de quien lo filtra.
• Qué información nunca entra a un prompt: la lista concreta de datos que bajo ninguna circunstancia se pegan en una herramienta de IA, sin ambigüedad ni excepciones de “depende del caso”.
• Herramientas aprobadas y proceso de alta: un catálogo cerrado de qué se puede usar hoy, y un camino claro para pedir que se sume una herramienta nueva sin tener que romper la regla para probarla.
• Cuándo hay que declarar uso de IA: en qué tipos de entregable el equipo tiene que decir, explícitamente, que una parte del trabajo se produjo con ayuda de IA.
• Uso aceptable y uso prohibido, con ejemplos reales: casos concretos de la operación diaria, no principios abstractos que cada quien interpreta a su manera.
• Consecuencias del incumplimiento: qué pasa cuando alguien se salta la política, con proporción según la gravedad y sin zonas grises.
• Dueño, firma y ciclo de revisión: quién la firma, quién responde por que se mantenga viva y cada cuánto tiempo se vuelve a mirar.

Los primeros seis puntos son la parte que el equipo necesita leer para operar: le dan la base para trabajar como un empleado AI Native sin quedar expuesto a un error que no vio venir. El séptimo es la parte que evita que el documento se firme una vez y se olvide en una carpeta compartida que nadie vuelve a abrir.

Qué información nunca puede entrar a un prompt

Este es el punto que más dolores de cabeza evita, y el que con más frecuencia queda redactado en términos tan vagos que no sirve para nada (“usar la IA de forma responsable” no le dice a nadie qué no puede pegar en un prompt). Conviene bajarlo a una lista concreta, por tipo de dato, no por tipo de herramienta:

• Datos personales de clientes: nombres completos, documentos de identidad, teléfonos, direcciones o historial de compra que identifique a una persona real.
• Información financiera no publicada: cifras de ventas, márgenes, proyecciones o estados financieros que la empresa no haya hecho públicos.
• Código fuente propietario y credenciales: claves de acceso, tokens, contraseñas o fragmentos de sistemas internos que le dan a alguien acceso a algo que no debería tener.
• Contratos y cláusulas confidenciales: acuerdos con clientes, proveedores o socios que incluyan condiciones que la otra parte espera que se mantengan privadas.
• Estrategia comercial no anunciada: planes de lanzamiento, precios futuros o movimientos competitivos que todavía no son públicos.

La razón de fondo no es solo la fuga hacia afuera. Si los datos de tu empresa terminan entrenando ese modelo es algo que depende de la configuración exacta de cada herramienta, y esa configuración cambia con cada actualización de cada proveedor. Escribir la política asumiendo que “la IA no guarda nada” es la forma más rápida de que quede desactualizada en tres meses. Se escribe asumiendo lo contrario: que cualquier dato que entra a un prompt puede quedar guardado en algún lugar fuera del control de la empresa, salvo que el contrato con ese proveedor diga expresamente lo opuesto.

Qué herramientas quedan aprobadas y cómo se suma una nueva

El catálogo de herramientas aprobadas cumple una función más importante de lo que parece: le da al equipo una respuesta rápida a la pregunta “¿puedo usar esto?”, en vez de dejarlo decidir solo con la información que tiene a mano. La lista no necesita ser larga. Necesita distinguir, para cada herramienta, si la cuenta es corporativa o personal, si existe un acuerdo de tratamiento de datos con ese proveedor, y para qué tipo de tarea está aprobada. Una herramienta con cuenta corporativa y contrato de por medio no es lo mismo que la versión gratuita de la misma herramienta, aunque el nombre en pantalla sea idéntico.

El proceso para sumar una herramienta nueva tiene que ser más corto que el impulso de usarla sin permiso. Si pedir autorización toma tres semanas de comités, el equipo va a seguir el camino de menor resistencia y va a usarla igual, sin pedirla. Funciona mejor con un formulario corto (qué herramienta, para qué la necesita, qué tipo de dato va a tocar) y un responsable único que evalúa y responde en días, no en meses. Ese mismo responsable es quien más adelante define, junto con el área que la pidió, cómo se debe limitar lo que ese sistema puede responder cuando interactúa directamente con un cliente.

Cuándo hay que declarar que un trabajo se hizo con IA

No todo lo que se produce con ayuda de IA necesita una etiqueta. Pedirle a una herramienta que revise la ortografía de un correo interno no es lo mismo que usarla para redactar un informe financiero que un cliente va a leer como si lo hubiera escrito, de principio a fin, un analista de la empresa. La declaración tiene sentido cuando el resultado se entrega hacia afuera (a un cliente, a un regulador, a un socio) o cuando reemplaza un juicio profesional que alguien asumía que era humano de principio a fin.

En la práctica funciona mejor con una regla simple: si el entregable final se apoyó en IA para una parte sustancial del contenido (no solo revisión de forma), se declara. Un análisis, un dictamen, una pieza de contenido publicada a nombre de la empresa: ahí se declara. Un corrector de estilo sobre un párrafo que la persona ya escribió: ahí no hace falta. La razón para declarar no es exponer a nadie, es que si después algo sale mal (por ejemplo, si la IA entrega información incorrecta a un cliente) la empresa necesita poder reconstruir qué parte del proceso fue automática y cuál tuvo revisión humana.

Qué pasa si alguien incumple la política

Una política sin consecuencias es una sugerencia, y el equipo lo nota rápido. Pero la consecuencia tiene que ser proporcional a la falta, o el documento se vuelve tan rígido que nadie lo respeta porque lo percibe como una amenaza vacía o como un exceso. No es lo mismo que alguien pegue por error un dato que no debía en una herramienta ya aprobada, a que alguien use deliberadamente una cuenta personal para sacar información de un cliente hacia afuera de la empresa.

• Falta accidental y sin daño real: conversación directa con la persona, recordatorio del punto exacto de la política que se saltó y ajuste del proceso para que no vuelva a pasar.
• Reincidencia o falta con algún daño: proceso disciplinario formal, igual que con cualquier otra falta operativa de gravedad comparable dentro de la empresa.
• Fuga deliberada de información sensible: el caso más serio, que la empresa debe tratar con la misma seriedad que cualquier otra fuga de datos, evaluando cada situación según su propio contexto y con quien corresponda dentro de la organización.

Lo que no funciona es dejar la consecuencia sin escribir, asumiendo que “ya se entiende”. El equipo entiende lo que está escrito, no lo que se sobreentiende, y una política que amenaza en abstracto sin decir qué pasa en concreto termina sin aplicarse la primera vez que alguien la incumple de verdad.

Quién la firma y cada cuánto se revisa

La política necesita un patrocinador visible arriba (gerencia general o el nivel equivalente) y un dueño operativo que la mantenga viva en el día a día, casi siempre alguien de sistemas o de seguridad de la información. El patrocinador de arriba es el que le da peso real al documento: si el equipo percibe que es un papel que bajó de sistemas sin respaldo de la gerencia, lo trata como tal. Conviene también que alguien de legal o de cumplimiento de la empresa la revise antes de firmarla, no porque el documento en sí sea jurídico, sino porque esta política es, en la práctica, la forma más concreta en que la empresa practica la IA responsable puertas adentro, más allá de la declaración de principios.

La revisión no puede ser “cuando alguien se acuerde”. Funciona mejor con una cadencia fija (por ejemplo, una vez al año) más una revisión extraordinaria cada vez que entra al mercado una herramienta nueva de uso masivo, porque ese es el momento en que la política real (la que el equipo practica) se distancia más rápido de la política escrita. Y firmarla no alcanza: si el lanzamiento no viene acompañado de capacitar al equipo para adoptarla de verdad, el documento queda firmado y archivado mientras el uso real sigue las mismas costumbres de antes.

La plantilla que uso para escribirla (y por qué no reemplaza a un abogado)

Antes de la plantilla, una aclaración necesaria: esto no es asesoría legal. Lo que sigue es una estructura organizativa, un punto de partida para ordenar las ideas antes de sentarse con quien corresponda dentro de cada empresa (legal, cumplimiento, recursos humanos, según el caso), no un documento jurídico listo para firmar tal cual. Cada país, cada industria y cada empresa tienen condiciones distintas, y esta plantilla no las conoce.

• Propósito y alcance: para qué existe el documento y a quién cubre.
• Roles y responsables: quién patrocina, quién administra y quién resuelve dudas del día a día.
• Catálogo de herramientas aprobadas y proceso de alta: qué se puede usar hoy y cómo se suma algo nuevo.
• Información que nunca se comparte: la lista concreta, sin ambigüedad, de qué no entra a un prompt.
• Casos de uso aceptados y prohibidos, con ejemplos: situaciones reales de la operación, no principios generales.
• Obligación de declarar contenido producido con IA: en qué entregables y bajo qué criterio.
• Consecuencias del incumplimiento: proporcionales según la gravedad de cada caso.
• Firma, vigencia y ciclo de revisión: quién la firma y cada cuánto se vuelve a mirar.

Para ordenar los roles y los controles de este último punto, algunas empresas toman como referencia de estructura (no como obligación legal) marcos de gestión de riesgo de IA ya publicados, como el que mantiene el NIST, útiles para pensar en términos de gobierno, roles y controles aunque la empresa no esté sujeta a ninguna norma que los exija.