En enero de 2023, el instituto de estándares de Estados Unidos (NIST) publicó la primera versión de un marco para ayudar a las organizaciones a evaluar el riesgo de la IA. El documento nació porque ni los propios especialistas lograban ponerse de acuerdo sobre qué significa realmente cada término del sector en la práctica — y si un organismo técnico del gobierno estadounidense necesitó un marco solo para eso, la vara está aún más alta para quien solo necesita decidir si compra o no una herramienta.
La Unión Europea siguió el mismo camino. La regulación europea de IA, actualizada en agosto de 2026, organiza los sistemas de IA en cuatro niveles de riesgo — de "riesgo inaceptable" a "riesgo mínimo" — en un intento explícito de darle al mercado un lenguaje común, en vez de dejar que cada proveedor defina sus propios términos a su manera. Es una señal clara: si organismos reguladores enteros están creando un diccionario, es porque el vocabulario natural del sector no le sirve a quien necesita decidir.
Del lado de quien compra, "The State of AI in the Enterprise", el estudio de Deloitte con más de tres mil líderes encuestados entre agosto y septiembre de 2025, señala la falta de capacitación como la principal barrera para llevar la IA de las pruebas de concepto al uso real dentro de las empresas. Y esa brecha no se queda en el nivel del equipo — sube hasta el escritorio de quien firma el contrato.
La distancia entre la propuesta comercial y la decisión
Una propuesta comercial de IA suele llegar cargada de términos técnicos: modelo propietario, algoritmo de última generación, infraestructura escalable, integración nativa, IA responsable, seguridad de nivel empresarial. Cada uno de esos términos suena bien y no significa nada por sí solo — porque ninguno describe lo que realmente va a pasar dentro de la empresa al día siguiente de firmar.
El problema no es falta de inteligencia de quien decide. Es una asimetría de información clásica: el proveedor conoce cada detalle técnico de su propio producto, y quien compra depende por completo de lo que ese mismo proveedor decida explicar. Cuando la explicación viene llena de términos técnicos y no se hace ninguna pregunta de negocio de vuelta, la decisión termina basándose en cuán convincente fue la presentación — no en cuán adecuado es el producto para esa empresa en particular.
Eso explica por qué tantas empresas firman un contrato de IA entusiasmadas con la demostración y descubren, meses después, que la herramienta no hace lo que parecía hacer, o lo hace de una forma que nadie sabe explicar cuando algo sale mal.
El costo de ese tipo de decisión rara vez aparece en la primera factura. Aparece en la renovación del contrato, cuando el equipo de TI descubre que la "integración nativa" prometida en la venta, en la práctica, exige un proyecto aparte para funcionar; o en medio de una auditoría, cuando nadie logra explicar por qué una respuesta específica de la IA citó una política que llevaba meses desactualizada.
Aprender la jerga no es el camino
La reacción más común, frente a esa distancia, es pensar que la solución es que la dirección "estudie más sobre IA" — leer artículos, ver charlas, acumular vocabulario técnico hasta poder seguir la conversación con el proveedor en el mismo nivel.
Eso no escala y no es el problema real. Nadie que dirige una empresa tiene tiempo de convertirse en especialista técnico en IA antes de cada decisión de compra, y hasta quien estudia lo suficiente para reconocer un término aún no sabe verificar si es cierto en ese producto específico — porque el término, por sí solo, no es verificable. "Seguridad de nivel empresarial" puede significar casi cualquier cosa, y memorizar su definición no ayuda a saber si ese proveedor en particular cumple la promesa.
Lo que realmente funciona es otra cosa: para cada término técnico de una propuesta comercial existe una pregunta de negocio concreta que revela si eso existe de verdad — sin exigir que quien pregunta entienda la capa técnica detrás. La pregunta correcta no le pide al proveedor una explicación. Le pide una demostración.
Lo que tiene que existir en la práctica
Detrás de cualquier promesa de IA "segura" o "responsable" existen mecanismos concretos que se pueden pedir ver funcionando, no solo descritos.
Identidad corporativa, no cuenta paralela. El acceso debería venir del mismo directorio que la empresa ya usa para el correo y la red — sin otro registro que administrar y sin otra lista de quién tiene acceso a qué.
Acceso según el papel de cada persona. Cada persona y cada agente deberían ver solo lo que su papel autoriza, incluso dentro de una única herramienta conectada — no la herramienta entera habilitada porque "era más simple así".
Aprobación humana según el riesgo. Una acción sensible debería detenerse y pedir confirmación de alguien antes de seguir adelante, dentro de la misma conversación — no después, en un informe que nadie lee.
Un registro de auditoría. Crear un agente, aprobar un documento, cambiar un permiso: todo debería quedar registrado de una forma que la propia empresa pueda consultar, sin depender del soporte del proveedor.
Conocimiento aprobado, con fuente. Una respuesta basada en conocimiento interno debería poder mostrar de qué documento vino, y quién aprobó ese documento como fuente confiable.
Es exactamente ese tipo de mecanismo — verificable, no solo descrito — el que la Skyller muestra desde la primera demostración: identidad proveniente del directorio de la empresa, permiso por papel y aprobación registrada como estándar, no como configuración escondida.
Lo que cambia cuando se hace la pregunta correcta
Una pregunta de negocio bien planteada hace que el propio proveedor muestre sus cartas. Un proveedor que realmente tiene control de acceso por papel muestra la pantalla de permisos en segundos, porque existe y es simple de exhibir. Un proveedor que solo tiene la palabra "seguridad" en el material de ventas duda, cambia de tema, o promete "enviar más detalles por correo después".
Esa diferencia de reacción vale más que cualquier certificado presentado en la propuesta. Un certificado describe un proceso interno del proveedor; una demostración en vivo muestra el producto que la empresa realmente va a usar. Y la ganancia no se queda solo en la decisión de compra: un equipo entrenado para pedir la demostración en vez de aceptar el término técnico lleva ese hábito a la próxima renovación de contrato, y a la próxima propuesta de cualquier otro proveedor de tecnología — no solo de IA.
Un diccionario al revés para la próxima reunión
Para la próxima conversación con un proveedor de IA, lleve estas seis traducciones — de término técnico a pregunta de negocio:
- "Nuestra IA aprende con los datos de la empresa." Pregunte de qué documento específico vino una respuesta y quién aprobó ese documento como fuente confiable. "Aprende sola de todo" es una respuesta que revela que no existe control.
- "Seguridad de nivel empresarial." Pida ver la pantalla de permisos, no el certificado. ¿Quién, específicamente, puede ver qué?
- "Integración nativa con sus sistemas." Pregunte si el acceso viene del mismo directorio que la empresa ya usa, o si es un registro nuevo y paralelo — otra contraseña, otra lista, otro punto ciego cuando alguien se vaya.
- "IA responsable" o "IA con gobernanza." Pregunte si existe un solo lugar donde aparecen las acciones que pidieron aprobación humana antes de ocurrir. Si la respuesta es que la IA es demasiado confiable para necesitar eso, la gobernanza es discurso.
- "Escalable para toda la empresa." Pregunte si se puede empezar con una sola área, con presupuesto y permisos aislados de ella. Si solo se puede comprar para todos a la vez, no es escalable — es todo o nada.
- "Registro completo de auditoría." Pregunte si se puede exportar quién creó, aprobó o cambió algo específico, en un intervalo de fechas, sin abrir un ticket de soporte. Si depende de que el proveedor ejecute una consulta interna, el registro existe para él, no para la empresa.
