No tienes que confiar en FlameP. Tienes que poder verificarlo.

1. El verdadero problema es la asimetría

Hoy, un sistema digital puede llegar a saber mucho sobre su usuario.

El usuario sabe sorprendentemente poco sobre el sistema.

Ve una interfaz. Ve una respuesta. Tal vez vea también el nombre de un modelo.

Por debajo pueden desarrollarse numerosos procesos técnicos. La información se selecciona, complementa, almacena, envía a sistemas externos, se procesa allí y posteriormente vuelve a ensamblarse. Otro modelo puede revisar la primera respuesta. Un motor de búsqueda puede aportar fuentes. Un sistema de seguridad puede clasificar contenidos. Puede haberse añadido contexto personal que el usuario ni siquiera introdujo en esa conversación concreta.

El problema comienza cuando la persona solo ve el resultado final y ya no tiene ninguna posibilidad razonable de comprender cómo se produjo.

Ni siquiera para los operadores de estos sistemas resulta evidente disponer de una visión completa. El National Institute of Standards and Technology estadounidense señala expresamente en su AI Risk Management Framework que los sistemas de IA pueden estar compuestos por numerosos componentes y actores interdependientes. Por ello, los responsables de una parte del sistema suelen carecer tanto de visibilidad como de control completos sobre otras partes. NIST recomienda, entre otras cosas, responsabilidades documentadas, una gestión continua de riesgos, la supervisión de los sistemas de terceros utilizados y decisiones trazables durante todo el ciclo de vida. [1]

Si incluso la organización que construye una aplicación de IA tiene que ocuparse activamente de comprender su propia cadena de suministro tecnológica, resulta sencillamente absurdo exigir al usuario que confíe sin más.

2. La transparencia aún no es una prueba

Las empresas, y también FlameP, suelen responder a esto con transparencia.

Explicamos qué proveedores utilizamos.

Publicamos una política de privacidad.

Describimos nuestras medidas de seguridad.

Eso es necesario, pero no suficiente.

La información sobre lo que teóricamente debería suceder no es lo mismo que una prueba de lo que realmente sucedió en un caso concreto.

Un ejemplo sencillo:

Una plataforma puede escribir que elimina los datos personales después de un período determinado.

Esa es una regla.

Una prueba sería otra cosa. Tendría que poder mostrar que la regla de eliminación correspondiente se ejecutó realmente para un conjunto de datos concreto.

Lo mismo se aplica a la IA.

Idea centralSolo utilizamos el contexto necesario para tu tarea.

Eso es una promesa.

Idea centralPara esta tarea concreta se utilizaron las áreas de información A y B; el área C quedó excluida.

Eso es más verificable.

Idea centralTrabajamos con varios proveedores de IA y elegimos el modelo adecuado.

Eso es una descripción del producto.

Idea centralEsta tarea se procesó el 10 de agosto con el modelo X del proveedor Y porque pertenecía a esta clase de tareas.

Eso es una prueba de un proceso concreto.

Es precisamente esta distinción la que nos interesa.

El derecho de protección de datos también la reconoce. El principio de responsabilidad proactiva del RGPD no solo exige cumplir los principios de protección de datos. Los responsables también deben poder demostrar su cumplimiento. El Comité Europeo de Protección de Datos señala expresamente que, en la práctica, esto implica, entre otras cosas, documentar las decisiones y los procesos de protección de datos. [2] [3]

Esta es una actitud distinta de «Confía en nosotros, lo hacemos bien».

Dice así: si una afirmación es relevante, debemos ser capaces de presentar evidencia que la respalde.

3. La regulación ya avanza en esta dirección

El AI Act europeo también recoge esta idea para determinados sistemas de IA.

Para los sistemas de IA de alto riesgo, el Reglamento exige, entre otras cosas, medios técnicos que permitan registrar automáticamente los acontecimientos. Además, estos sistemas deben diseñarse con suficiente transparencia para que los operadores puedan interpretar y utilizar adecuadamente sus resultados. Entre los requisitos también figura información sobre las capacidades, las limitaciones de rendimiento, el uso previsto y, cuando proceda, los mecanismos para analizar los registros. Para los sistemas de alto riesgo, el AI Act exige asimismo medios adecuados de supervisión humana. [4]

No deberíamos extraer de esto la conclusión errónea de que todos los productos de IA están sujetos a las mismas obligaciones. No lo están. El AI Act opera deliberadamente con distintas categorías de riesgo y requisitos diferentes.

Por eso, el principio subyacente nos parece más interesante que la clasificación jurídica.

Un sistema técnicamente complejo no se vuelve más digno de confianza porque su fabricante asegure que lo es.

La confiabilidad necesita estructuras, documentación, registro, responsabilidades, posibilidades de control y límites conocidos.

Y la capacidad de reconstruir posteriormente los errores.

El NIST AI Risk Management Framework aborda precisamente estos puntos como parte de una gobernanza continua. La documentación debe mejorar la transparencia, facilitar la revisión humana y reforzar la rendición de cuentas. El marco también exige documentar y revisar periódicamente las funciones, los riesgos, los componentes externos, la supervisión humana y los límites del sistema. [1]

La OECD va ahora un paso más allá. Su Due Diligence Guidance for Responsible AI, publicada en 2026, vincula las obligaciones clásicas de diligencia debida empresarial con la gobernanza de la IA. Las empresas deben identificar riesgos y posibles efectos negativos, aplicar medidas, hacer un seguimiento de sus resultados, comunicarlos y, cuando proceda, posibilitar medidas de reparación. [6]

Es el paso de la afirmación a la verificabilidad.

4. Pero ¿qué debe verificar realmente una persona corriente?

Aquí la cuestión se complica.

Podríamos mostrar a un usuario un informe técnico con 300 entradas después de cada sesión de FlameP.

Marcas de tiempo, llamadas a API, versiones de modelos, cantidades de tokens, valores hash, operaciones de almacenamiento, objetos de permisos, eventos de red.

Sería transparente, pero no útil.

Porque la propia transparencia puede convertirse en una forma de ocultamiento. O, dicho de otro modo: «Beat them with details».

Quien abruma a las personas con suficiente información puede afirmar después que lo ha revelado todo. Pero nadie lo ha entendido.

Conocemos este patrón desde hace mucho tiempo por los términos y condiciones generales y los diálogos de cookies. Formalmente se explican muchas cosas. En la práctica, la persona hace clic en «Aceptar» porque no quiere invertir media jornada laboral antes de poder utilizar un sitio web.

Para FlameP, pruebas antes que confianza no significa, por tanto, información máxima.

Significa verificabilidad relevante.

El usuario no tiene que entender cómo funciona matemáticamente un Transformer.

En un uso normal, tampoco tiene que revisar el algoritmo interno completo de routing.

Pero debería poder obtener respuestas a algunas preguntas muy sencillas.

¿Qué sabía FlameP para esta tarea?

¿Adónde fue la información?

¿Qué ocurrió con ella?

¿Qué decidió una máquina?

¿Qué decidió una persona?

¿Qué permanece almacenado?

¿Y qué ha finalizado ya?

Desde nuestro punto de vista, la verdadera función de una buena capa de transparencia no es mostrarlo todo. Para nosotros, transparencia significa mostrar lo correcto.

5. Por eso necesitamos distintos niveles de prueba

No concebimos la verificabilidad como un único archivo de registro enorme.

Se necesitan al menos tres niveles.

El primero pertenece al usuario.

Debe ser comprensible.

Para una tarea relevante, una persona debería poder comprender, por ejemplo, qué espacio de FlameP se utilizó, qué áreas de contexto estaban autorizadas, qué proveedor participó y si el procesamiento terminó.

No en lenguaje para desarrolladores.

Sino más o menos así:

Idea centralContexto utilizado: proyecto FlameP y perfil público de autor.

Idea centralNo utilizado: conversaciones personales, información de salud, otros proyectos.

Idea centralProcesamiento externo: proveedor X, modelo Y.

Idea centralAlmacenamiento por parte del proveedor: según las condiciones aplicables a esta ruta.

Idea centralEstado de FlameP: tarea finalizada, autorizaciones temporales cerradas.

Esto no es una auditoría completa.

Es un comprobante comprensible.

Nosotros mismos necesitamos el segundo nivel.

En él debe poder documentarse con mucho más detalle lo sucedido técnicamente. De lo contrario, no podremos investigar errores, reconstruir problemas de seguridad ni controlar nuestras propias reglas.

El tercer nivel resulta necesario cuando un control independiente es razonable u obligatorio.

Auditores, autoridades de supervisión u otras entidades autorizadas pueden necesitar pruebas más profundas que un usuario corriente no tiene por qué ver ni debería ver.

Tres niveles.

Comprensibilidad para las personas.

Reconstrucción para el operador.

Verificabilidad para el control independiente.

6. Sin embargo, esto crea un nuevo problema

El registro puede convertirse por sí mismo en recopilación de datos.

Es una de esas bonitas contradicciones que suelen desaparecer en una presentación.

Queremos poder demostrar lo mejor posible qué ocurrió con los datos, así que registramos tanto como sea posible. Y de repente hemos construido una nueva base de datos que documenta con bastante precisión qué hizo una persona y cuándo.

Sería absurdo.

Por eso, pruebas antes que confianza no puede significar conservar para siempre cada proceso vinculado a una persona. Las pruebas también necesitan minimización de datos.

El RGPD menciona la minimización de datos, la limitación de la finalidad y la limitación del plazo de conservación como principios fundamentales. Las organizaciones solo deben tratar información personal en la medida y durante el tiempo necesarios para la finalidad correspondiente. [3]

Para FlameP, esto supone un difícil ejercicio de equilibrio técnico.

Debemos poder demostrar que algo ocurrió sin conservar innecesariamente todo el contenido de lo sucedido.

A veces puede registrarse un evento sin almacenar su contenido.

A veces basta con saber que se había autorizado un tipo determinado de contexto, sin copiar el contexto completo en el registro de auditoría.

A veces una referencia técnica puede demostrar que estaba vigente una versión determinada de una Policy sin volver a almacenar todos los datos del usuario.

Y a veces será necesaria una prueba más detallada.

Esto no puede resolverse con un único interruptor. Es un arduo trabajo de arquitectura.

7. Las respuestas de IA lo hacen aún más difícil

Supongamos que FlameP muestra claramente:

Se utilizó este modelo. Se consultaron estas fuentes. Este contexto estaba autorizado. Estos permisos estaban vigentes.

Todo eso está muy bien, pero, por supuesto, no demuestra que la respuesta sea correcta.

Este es un límite importante de nuestro principio. En muchos resultados de IA, FlameP no puede demostrar que una afirmación sea verdadera. Un modelo de lenguaje puede cometer un error pese a que el proceso sea impecable.

Dos modelos pueden equivocarse. Una fuente puede estar desactualizada. Un estudio científico puede refutarse posteriormente. Una decisión empresarial puede fracasar pese a un análisis excelente.

Por eso, pruebas antes que confianza tampoco debe convertirse en la ilusión de una seguridad absoluta.

En muchos casos podemos hacer que el proceso sea más demostrable. ¿Qué fuentes se utilizaron? ¿Qué revisión se realizó? ¿Qué incertidumbres se detectaron? ¿Se utilizó un segundo modelo? ¿Una persona aprobó el resultado? ¿Qué versión de una información estaba disponible en ese momento?

Aun así, el resultado sigue siendo una decisión bajo incertidumbre.

Precisamente por eso, NIST también distingue entre las distintas características de una IA digna de confianza. La transparencia, la explicabilidad, la protección de datos, la seguridad, la fiabilidad y la rendición de cuentas están relacionadas, pero ninguna de ellas garantiza por sí sola que un sistema actúe correctamente en todas las situaciones. [1]

Por tanto, no queremos convertir «Confía en la IA» en un nuevo «Confía en el Audit-Log».

La prueba no sustituye al razonamiento, pero crea una base mejor para él.

8. Los proveedores tampoco deben desaparecer detrás de FlameP

Una de las opciones más cómodas al construir una plataforma con múltiples proveedores sería hacer que la complejidad técnica resultara completamente invisible.

El usuario habla con FlameP.

Nosotros elegimos el modelo en segundo plano.

Listo. Sería agradable, pero tendría un precio.

FlameP se convertiría en un nuevo punto central de confianza. El usuario dejaría de depender directamente de un único proveedor de modelos, pero tendría que creer que nosotros siempre hacemos lo correcto en segundo plano.

Esa sería precisamente la dependencia que queremos reducir.

Por eso, para nosotros, la transparencia sobre los proveedores forma parte de pruebas antes que confianza.

Esto no significa que alguien tenga que tomar primero cinco decisiones técnicas ante cada consulta sencilla. Un buen sistema puede organizar la complejidad.

Pero las decisiones relevantes deben poder reconstruirse. ¿Qué proveedor se eligió? ¿Por qué estaba permitida esta ruta? ¿Qué clase de datos podía llegar a ese proveedor? ¿Qué versión de la regla estaba vigente? ¿Había una alternativa?

¿Se trató una tarea especialmente sensible de manera diferente a un borrador de texto trivial?

Los OECD AI Principles destacan expresamente, además de la transparencia y la explicabilidad, la rendición de cuentas y la trazabilidad como elementos de una gobernanza responsable de la IA. [5]

Para nosotros, la trazabilidad no es un lujo técnico.

La trazabilidad determina si la independencia de los proveedores crea verdadera independencia o tan solo un nuevo intermediario opaco.

9. Pruebas antes que confianza también se aplica a nosotros mismos

Hasta aquí podría surgir la impresión de que FlameP quiere demostrar principalmente lo que otros proveedores hacen con los datos.

Si decimos que el contexto personal permanece separado, nuestros sistemas deben imponer realmente esa separación.

Si afirmamos que un espacio de FlameP solo tiene acceso a determinada información, no puede estar disponible en segundo plano todo el historial personal.

Si un permiso temporal terminó, debe haber terminado técnicamente.

Si afirmamos que una tarea ha finalizado, las conexiones temporales creadas para ella no deberían seguir existiendo indefinidamente.

Si decimos que un proceso determinado no se almacena, nuestros propios registros deben ajustarse a esa promesa.

Y si algo todavía no funciona, no podemos escribir como si ya funcionara.

La visión del producto y la realidad del producto avanzan a velocidades diferentes. Se aprueba un concepto en un taller. La interfaz de usuario ya muestra el nuevo lenguaje. Pero en el backend todavía falta una parte de la implementación técnica.

La empresa empieza a hablar del producto que quiere construir como si ya fuera el producto que las personas utilizan.

Capability antes que Claim.

El sistema debe poder respaldar lo que afirmamos.

Y si todavía no puede hacerlo, lo llamamos plan, objetivo o desarrollo. No función.

10. Lo mismo se aplica al impacto social

Este punto conecta pruebas antes que confianza directamente con nuestra estrella polar del flujo de valor.

Supongamos que FlameP decide asignar 20.000 euros a un programa social.

Eso puede significar al menos cinco cosas diferentes. Hemos calculado que, según nuestra regla, se destinarían 20.000 euros a ese fin. Hemos reservado internamente esa cantidad.

La hemos comprometido de manera vinculante con un proyecto. La hemos transferido realmente.

O podemos demostrar además que el dinero llegó y se utilizó para la finalidad descrita.

Estos cinco estados no son lo mismo.

En la comunicación empresarial suelen agruparse.

«20.000 euros para el impacto social». Suena maravilloso. Pero después nadie sabe ya qué ocurrió realmente.

Queremos separar estos estados, y desde luego no porque la contabilidad sea nuestro pasatiempo favorito.

Sino porque el impacto social es especialmente susceptible al autoengaño bienintencionado.

Lo mismo se aplica a las aplicaciones.

Si escribimos que FlameP admite un idioma determinado, debe aclararse qué significa «admite».

¿Puede el sistema traducir algunas frases? ¿Puede una persona nativa trabajar realmente con él? ¿Evaluaron la calidad personas que hablan ese idioma? ¿Funciona la entrada de voz? ¿Funciona solo en una demostración o en el producto real?

11. Aun así, la transparencia total sería un error

Existe una concepción romántica de la transparencia: si todo fuera abierto, todo estaría bien. Pero no es cierto.

Un sistema de seguridad no debería publicar todas sus reglas internas de protección. De lo contrario, proporcionaría directamente las instrucciones a posibles atacantes.

Un usuario no debería poder ver los datos personales de otros usuarios solo porque hayamos prometido transparencia.

Los secretos comerciales y la propiedad intelectual tampoco desaparecen porque una empresa quiera actuar responsablemente.

Y cierta información técnica no solo es incomprensible, sino completamente irrelevante para la decisión concreta. Por eso, pruebas antes que confianza no significa divulgación radical.

Significa verificabilidad proporcional.

¿Qué debe saber o poder verificar un actor determinado para evaluar una afirmación relevante?

El usuario necesita una perspectiva distinta de la de un auditor de seguridad. Una autoridad de protección de datos necesita una distinta de la de un cliente. Un desarrollador necesita información diferente de la que necesita un auditor.

Por buenas razones, NIST trabaja con funciones, responsabilidades documentadas y distintos procesos de revisión, en lugar de imponer un único requisito universal de transparencia. [1]

12. Pero algo muy importante: aun así hará falta confianza

Ahora sería bastante fácil utilizar nuestro principio contra nosotros.

Si todo debe demostrarse, ¿por qué seguir necesitando confianza? Porque ningún sistema complejo funciona sin confianza. Ninguna persona corriente leerá el código fuente de todos los componentes de FlameP. Nadie inspeccionará personalmente los centros de datos de cada proveedor.

Incluso un auditor independiente solo examina ciertas áreas en momentos determinados.

Las certificaciones pueden contener errores. Los Logs pueden implementarse incorrectamente. Las leyes se incumplen. Las personas cometen errores. Siempre habrá un límite a lo que un usuario individual pueda verificar por sí mismo. Por eso, nuestro objetivo no es abolir la confianza.

Nuestro objetivo es reducir el ámbito en el que resulta necesaria la confianza ciega.

Hoy, muchas cosas funcionan según este principio: confía primero en nosotros. Quizá más tarde puedas verificar si lo merecíamos. Queremos invertir el orden: mostramos tanta evidencia relevante como resulte razonablemente posible. De ahí puede surgir la confianza.

13. Esto también modifica la distribución del poder

En última instancia, pruebas antes que confianza no es una cuestión técnica de detalle.

Se trata de poder.

Quien es el único que sabe qué hizo un sistema posee una ventaja informativa.

Quien puede decidir por sí solo qué información se hace visible controla el relato al respecto.

Y quien, al mismo tiempo, posee los datos, determina las reglas y formula por sí mismo la prueba del cumplimiento de esas reglas exige una cantidad considerable de confianza.

No podremos eliminar por completo esta asimetría. FlameP opera el sistema. Por tanto, inevitablemente tenemos poder. La cuestión relevante no es si el poder existe. Para nosotros, la cuestión relevante es cómo construir mecanismos que lo limiten.

La documentación limita el poder. Los permisos trazables limitan el poder. La separación del contexto limita el poder. Un proveedor visible limita el poder. Las revisiones independientes pueden limitar el poder.

Y una cultura empresarial en la que una afirmación necesita una prueba limita, al menos, la tentación de acercar demasiado la realidad y el marketing.

La OECD también vincula ya expresamente la IA responsable con un proceso continuo de identificación de riesgos, prevención, supervisión, comunicación y, cuando proceda, reparación. [6]

14. Conclusión: nuestra aspiración es sencilla. Su aplicación no lo será.

Hoy no sabemos hasta qué punto lograremos cumplirla en todos los ámbitos. Algunas pruebas serán técnicamente relativamente sencillas.

Otras serán costosas. Podremos presentar cierta información de manera comprensible.

En otros casos descubriremos que la transparencia y la protección de datos chocan entre sí.

Quizá al principio registremos cosas que más adelante tengamos que resolver de otra manera.

Quizá los usuarios descubran que nuestra interfaz de transparencia muestra la información equivocada.

Quizá una revisión externa nos señale un punto ciego que nosotros mismos no habíamos visto.

Pruebas antes que confianza no significa que no cometamos errores.

Significa que nuestro sistema se construye, en la medida de lo posible, de modo que los errores sean visibles, reconstruibles y corregibles.

Es una promesa más modesta. Y más exigente.

No queremos decir:

Idea centralFlameP es digno de confianza.

Eso sería una afirmación sobre nosotros mismos. Preferimos decir:

Idea centralEsto es lo que hizo FlameP. Estas son las reglas relevantes. Estos son los límites. Y esto es lo que puede verificarse.

Después, cada persona puede decidir por sí misma cuánta confianza se deriva de ello. Consideramos que ese orden es más honesto.

No tienes que confiar en FlameP. Nosotros tenemos que ganarnos esa confianza.

Y siempre que sea posible, nuestra palabra no debería bastar para ello.