Investigación y publicaciones técnicas
Papers técnicos y notas de ingeniería sobre arquitectura de sistemas, verificación adversarial, evolución controlada, privacidad, soberanía, inteligencia ambiental e IA de alta consecuencia. Las ediciones públicas explican principios y evidencia sin publicar detalles que permitan reproducir implementación propietaria.
Publicamos lo necesario para explicar la tesis, la arquitectura, la evidencia, los límites y sus consecuencias de ingeniería. No publicamos prompts internos, contratos de orquestación, umbrales operativos, configuraciones de seguridad, playbooks de despliegue ni otros detalles que permitan reproducir materialmente una implementación propietaria.
11 papers técnicos · 23 notas de ingeniería · arquitectura, evidencia, soberanía, evolución controlada y sistemas del mundo real
Tesis extensas con arquitectura, límites y evidencia.
Son ediciones técnicas públicas: deliberadamente profundas en principios y consecuencias, y deliberadamente incompletas en detalles capaces de reproducir implementación propietaria.
Si un sistema depende de su proveedor, no es arquitectura
Este paper argumenta que un sistema diseñado para operaciones críticas que depende de un único proveedor de modelos o infraestructura posee una arquitectura frágil, no una estratégica. Se analiza cómo esta dependencia introduce puntos de fallo técnicos, económicos y de gobernanza que comprometen la continuidad operativa. Se desarrolla una arquitectura conceptual basada en principios de soberanía tecnológica, componentes reemplazables a través de una capa de abstracción, portabilidad de datos y artefactos, y autoridad humana. Mediante un caso hipotético, se contrastan los resultados de una implementación dependiente frente a un diseño arquitectónico soberano ante un cambio adverso del proveedor. Finalmente, se proponen criterios de evaluación para medir la independencia de un sistema y se discuten las consecuencias de ceder el control operativo a terceros.
Por qué la IA industrial debería empezar fuera del lazo de control
En industria, minería y Oil & Gas, el costo de una decisión equivocada puede superar ampliamente el valor de una automatización temprana. Este paper propone una estrategia por capas: observar primero, correlacionar después, recomendar con evidencia y sólo automatizar capacidades acotadas cuando el comportamiento esté medido.
Por qué la evidencia importa más que la elocuencia
Los modelos pueden expresar una conclusión con más seguridad lingüística que evidencia disponible. Este paper propone una regla de ingeniería: la fuerza visible de una afirmación nunca debe superar la fuerza de su respaldo, y la ausencia de evidencia debe permanecer visible en el producto.
La privacidad no empieza en la política. Empieza antes del proveedor.
Una política contractual no evita que un dato sensible salga de la organización. Este paper analiza la privacidad como frontera técnica previa al proveedor: minimizar, detectar, transformar, verificar y registrar antes de permitir que un modelo externo reciba información.
El agente que escribe el código no debería aprobarlo
Cuando el mismo agente diseña, implementa, prueba y declara correcto su trabajo, la separación de funciones desaparece. Este paper explica por qué la no autoaprobación es una propiedad de arquitectura y no una preferencia organizacional.
Software que propone su sucesor pero no puede promoverlo
Un sistema capaz de detectar sus propias limitaciones puede proponer una generación sucesora sin recibir el poder de instalarla. Este paper describe la separación entre necesidad de evolución, generación de candidata, comparación, auditoría y promoción humana.
Argos: cuando la IA deja de esperar un prompt
La próxima frontera de IA no siempre comienza con una pregunta humana. En entornos físicos, el sistema recibe señales continuas, conserva contexto, detecta cambios y decide si debe ignorar, informar, pedir confirmación o actuar dentro de políticas explícitas. Este paper describe la diferencia entre un asistente y una inteligencia ambiental.
La firma humana es parte de la arquitectura
La aprobación humana suele tratarse como una pantalla final agregada por cumplimiento. Este paper sostiene que, en sistemas de alta consecuencia, la autoridad humana debe modelarse como un componente explícito: con información mínima necesaria, estados bloqueantes, responsabilidades y evidencia suficiente para decidir.
No le pregunto a la IA si mi idea es buena. Le pido que la destruya.
La inteligencia artificial suele utilizarse para justificar una idea ya elegida. Este paper sostiene lo contrario: una arquitectura de decisión seria debe asignar capacidad explícita a producir alternativas rivales, buscar evidencia contraria y diseñar pruebas que puedan destruir la hipótesis preferida antes de aprobarla.
Un modelo no es un sistema
Un modelo puede razonar, redactar o clasificar con enorme capacidad y aun así no constituir un sistema. Este paper propone una separación operacional entre modelo y sistema: la inteligencia generativa es un componente; la arquitectura es la que define propósito, contexto, evidencia, permisos, fallos, autoridad y efectos.
Soberanía de software en la era de los modelos fundacionales
Soberanía no significa ejecutar cada modelo localmente ni eliminar todo proveedor. Significa diseñar la arquitectura para que identidad, datos, reglas, evidencia y continuidad permanezcan bajo control de la organización y para que los proveedores sean sustituibles cuando sea razonable.
Argumentos más breves y posiciones de trabajo.
La voz soberana se diseña como infraestructura, no como suscripción
Cuando la telefonía es crítica, propiedad, datos, proveedor, modelo y continuidad operativa deberían ser decisiones de arquitectura y no condiciones impuestas por una plataforma.
→// Arquitectura de vozLa latencia de voz no es un problema de prompt
Una conversación telefónica con IA depende de toda la cadena de audio, orquestación y control. Cambiar de modelo no corrige por sí solo una arquitectura lenta.
→// Privacidad y soberaníaEl modelo nunca debería ver el valor real cuando no lo necesita
Privacidad por arquitectura significa separar lo que el modelo necesita para razonar de lo que la organización necesita conservar en secreto.
→// Ingeniería adversarialTodo sistema tiene agujeros. También el mío.
La diferencia profesional no está en afirmar que no existen fallos. Está en intentar encontrarlos antes de que los encuentre otra persona o la operación real.
→// Ingeniería adversarialUn sistema serio sabe cuándo bloquear
La autonomía no se mide sólo por cuántas cosas puede hacer. También por cuántas sabe negarse a hacer cuando faltan evidencia, permisos o condiciones seguras.
→// ArquitecturaContexto mínimo: darle a cada agente sólo lo que necesita
Más contexto no siempre produce mejores decisiones. También puede agregar ruido, exposición de datos y sesgos irrelevantes.
→// ArquitecturaArquitectura vs. prompt: cuándo una demo se vuelve sistema
Una buena instrucción puede producir una demo impresionante. Un sistema aparece cuando el comportamiento importante deja de depender de recordar la instrucción correcta.
→// IA reguladaLo que cambia cuando la IA entra en una operación regulada
En salud, legal, finanzas o datos personales, la pregunta deja de ser sólo si la IA funciona. También importa quién puede verla, qué dato recibió, qué hizo y quién autorizó el resultado.
→// Sistemas realesIntegrar IA sin reemplazar el CRM que ya funciona
El software viejo no siempre es el problema. A veces el problema es que la operación creció y el sistema que sigue funcionando nunca fue diseñado para voz, agentes, memoria o automatización actual.
→// ArquitecturaLa inteligencia no está en el modelo. Está en lo que lo rodea.
Memoria, contexto, herramientas, evidencia, permisos y recuperación convierten una capacidad lingüística en una operación confiable.
→// ArquitecturaPor qué un sistema debería detectar que necesita evolucionar
Mantenimiento reactivo espera a que alguien note el problema. Un sistema observable puede convertir fallos, trabajo manual y degradación en evidencia para proponer su próxima versión.
→// Privacidad y soberaníaSoberanía sin el muro de complejidad
Muchas organizaciones quieren controlar su tecnología pero abandonan cuando la alternativa parece exigir convertirse en una empresa de infraestructura. Ese muro también se puede diseñar.
→// Sistemas realesOmnicanal sin memoria compartida no es omnicanal
Poner WhatsApp, email, voz y web bajo el mismo logo no alcanza. Si cada canal olvida lo que pasó en el anterior, la operación sigue fragmentada.
→// Sistemas realesFit te dice quién. Timing te dice cuándo.
Una empresa puede parecer el cliente perfecto durante años y no tener intención de comprar. La oportunidad aparece cuando el encaje coincide con una señal fresca.
→// Sistemas realesUn lead score que nunca baja no mide nada
Un puntaje comercial útil debe poder perder confianza cuando faltan datos, una señal envejece o nueva evidencia contradice la hipótesis original.
→// Privacidad y soberaníaQué pasa cuando vulneran al proveedor de IA
La organización puede hacer todo bien y aun así depender de un tercero que falla. La arquitectura debe reducir qué valor tendría ese incidente para un atacante.
→// Privacidad y soberaníaPor qué existe Data Shield
Data Shield nació de una regla simple: si el modelo no necesita conocer el valor real, no hay razón para enviárselo.
→// Privacidad y soberaníaLo que enviás a una IA puede ser lo que ya no puedas borrar
La mejor forma de reducir el riesgo de retención externa es sencilla: que el proveedor nunca reciba el valor real cuando no lo necesita.
→// Sistemas realesUn bot responde. Un sistema recuerda.
La diferencia no es que un bot hable peor. Es que normalmente la conversación termina donde empezó: sin memoria común, sin operación y sin continuidad entre canales.
→// Privacidad y soberaníaTu política de IA no es un control de seguridad
Pedirle a las personas que recuerden qué pueden pegar en un modelo público es una política. Impedir técnicamente que el dato real salga es arquitectura.
→// Ingeniería adversarialMisma pregunta. Mismo documento. Una respuesta diferente.
Cuando una conclusión importante cambia con una nueva corrida, no tenés un hallazgo: tenés una opinión con buena gramática.
→// ArquitecturaEl problema no es dar más autonomía a la IA. Es saber cuándo no confiar en ella.
La autonomía útil necesita evidencia, permisos, trazabilidad, separación de funciones y capacidad de bloquear.
→// Ingeniería adversarialUsamos agentes de IA. No hacemos Vibe Coding.
Usar agentes para escribir código no elimina la ingeniería: aumenta la necesidad de especificación, evidencia y auditoría.
→