Diez preguntas que estropean una demo de IA y arreglan una compra.
No necesitas saber programar para hacer preguntas que una presentación bonita no puede contestar. Diez, y la que las ordena todas.
Dentro del expediente
La demostración funciona. El documento aparece. El comercial sonríe. Ahora empieza la parte interesante, que es comprobar qué ocurre fuera del recorrido perfecto que alguien ha preparado para ti.
Esta lista es un criterio de compra propuesto. No es una auditoría de ningún proveedor ni una denuncia de herramientas concretas. Se puede usar sin subir un solo expediente de cliente.
La pregunta que ordena todas las demás
Antes de las diez va una pregunta. ¿Qué pasa cuando esto falla? No cuando funciona con el caso de ejemplo, sino cuando falta un anexo, cuando el documento llega en un formato raro o cuando alguien cambia una cifra después de la revisión. La respuesta a esa pregunta ordena el resto de la conversación, porque separa lo que el sistema hace de lo que el folleto promete.
Si nadie del otro lado ha pensado en el fallo, el producto no tiene por qué ser malo, pero la parte de tu riesgo todavía no ha sido diseñada por nadie.
Datos y poder
1. ¿Qué datos necesita de verdad? Pide distinguir los necesarios de los que conviene no aportar. 2. ¿Quién puede acceder? Incluye al soporte y a los subproveedores. 3. ¿Qué puede ejecutar? Separa leer de editar, y las dos de enviar fuera del despacho.
4. ¿Cómo se aísla cada cliente? Pide evidencia de controles y una demostración pactada con expedientes de prueba. Una etiqueta visible en la interfaz no demuestra por sí sola separación técnica.
Aquí conviene recordar que un sistema con capacidad de actuar concentra el riesgo donde nadie mira. La guía de OWASP sobre agencia excesiva describe ese patrón con detalle Fuente primaria ↗, y merece la pena leerla antes de una reunión comercial, no después.
Revisión y reconstrucción
5. ¿Puedo abrir la fuente original? Que aparezca una cita no resuelve si existe, si sostiene la frase o si sigue vigente. 6. ¿Puedo devolver el trabajo? Busca un estado de duda y una vía de devolución, no solo un botón de aceptación.
7. ¿Qué versión se aprueba y cuál se entrega? Introduce un cambio después de la revisión y observa qué ocurre. 8. ¿Puedo reconstruir una salida? Pide una exportación comprensible de las versiones y de las decisiones que las cambiaron.
La séptima es la que pediría ver en pantalla. En una demostración preguntaría a qué se vincula la aprobación, al expediente o a la versión concreta. Si queda registrada contra el expediente, un cambio posterior hereda una firma que nunca lo vio.
Cambios y salida del proveedor
9. ¿Qué cambia cuando se actualiza el sistema? Pregunta qué evaluaciones se repiten y cómo se informa de cambios con efectos en tu flujo. 10. ¿Cómo me voy? Examina qué te llevas y en qué formato. Pregunta por plazos y por coste de salida, y por qué información dejaría de ser accesible el día que rescindas.
Una respuesta honesta de «esto no lo hacemos» puede ser más útil que un «cumplimos todo» sin detalles. Lo que se compra es una capacidad delimitada, no una promesa ilimitada.
Qué mirar cuando el software para asesorías se vende por cumplimiento
Cada vez más presentaciones apoyan la venta en la normativa. Se menciona el reglamento europeo y se enseña algún sello. Conviene separar tres cosas que suenan parecidas. Una norma de sistema de gestión certifica que existe un procedimiento, no que un resultado concreto sea correcto Fuente primaria ↗. Un marco voluntario ordena el análisis de riesgos, y nadie certifica a nadie por usarlo Fuente primaria ↗. Y el reglamento europeo obliga según el papel que ocupas y el tipo de sistema, no en bloque a todo el que use una herramienta Fuente primaria ↗.
Preguntaría directamente qué alcance exacto tiene ese certificado y qué sistema cubre, con su fecha. Si el alcance no aparece por escrito, el sello decora la presentación y poco más.
Convierte la demostración en un acta de aceptación
Antes de probar, define los escenarios y el resultado esperado. Deja por escrito quién valida. Trabaja siempre sobre datos inventados, en un entorno autorizado. Después anota qué se observó y qué quedó sin resolver. Las dudas con efecto material deberían resolverse antes de trasladar el flujo a producción, no en la primera semana de uso real.
Ese acta no tiene que ser un documento solemne. Media página con lo que se probó y lo que falló sirve mejor que un informe extenso que nadie relee después.
Qué haría yo con el resultado
Compraría por capacidades concretas, empezando por las tareas donde un error se ve pronto y se corrige barato. Ampliaría el alcance cuando pudiera enseñar por qué merece la pena. Y guardaría las respuestas del proveedor con su fecha, porque dentro de un año, cuando algo salga mal, la conversación empezará por lo que te dijeron entonces.
Para evitar que una demostración sea tu única diligencia de compra no hace falta atacar al proveedor.
Lo que me preguntan cuando cierro el portátil.
¿Qué hay que preguntar antes de contratar software de IA para un despacho?
Qué datos necesita de verdad, quién puede acceder incluyendo soporte y subproveedores, qué puede ejecutar por su cuenta y cómo se separa un cliente de otro. Después, si puedes abrir la fuente original y si podrás reconstruir una salida concreta meses más tarde.
¿Sirve una demostración para decidir una compra?
Sirve para ver el recorrido que alguien ha preparado. No sirve para saber qué ocurre cuando falta un documento o cambia una versión a mitad del proceso. Esa parte hay que pedirla expresamente, siempre sobre datos inventados.
¿Qué señal indica que un proveedor merece confianza?
Que conteste «esto no lo hacemos» cuando no lo hace. Un proveedor que dice cumplirlo todo sin poder enseñar cómo está vendiendo tranquilidad, no capacidad. La respuesta incómoda y concreta vale más que la cómoda y general.
Pide una prueba de fallo con datos inventados antes de contratar.
El expediente detrás del artículo.
LLM06:2025 · Agencia excesiva ↗OWASP GenAI Security Project · 2025Guía técnica de riesgosISO/IEC 42001:2023 ↗International Organization for Standardization · 2023
Norma de sistema de gestión de IAPerfil de riesgos de IA generativa ↗NIST · AI 600-1 · 2024
Marco técnico voluntarioReglamento europeo de inteligencia artificial ↗EUR-Lex · Reglamento (UE) 2024/1689 · 2024
Normativa UE; comprobar versión y calendario
Fuentes consultadas el 10 de septiembre de 2026. Las recomendaciones y ejemplos son elaboración editorial y no se atribuyen íntegramente a estas fuentes. Comprueba versión y ámbito antes de aplicar una norma.
Divulgación general. Ninguna herramienta de esta web certifica la revisión, seguridad o conformidad de un proceso.