DEV Community: Carlos Arturo Castaño G.

¿Por qué llamarle "Inteligencia" a un LLM es un extremo estadístico? Una perspectiva tras décadas en redes neuronales.

Carlos Arturo Castaño G. — Sun, 04 Oct 2026 15:14:58 +0000

Como profesional que ha trabajado con redes neuronales determinísticas y sistemas de e-learning desde hace ya varias décadas, observo el panorama actual de la Inteligencia Artificial con una mezcla de profunda admiración y escepticismo terminológico.

En los inicios de estas arquitecturas, a ninguno de nosotros se nos habría ocurrido pensar, ni por asomo, que allí dentro residía una "inteligencia en sí misma". Sabíamos exactamente lo que eran: aproximadores de funciones, álgebra lineal y optimización estadística.

Hoy en día reconozco plenamente las bondades de los Modelos de Lenguaje Grandes (LLMs). De hecho, los utilizo casi a diario para múltiples objetivos: desde la generación y estructuración de texto, pasando por la creación de videos y conversiones, hasta el soporte en tareas de programación. No cabe duda de que estamos ante una de las propuestas y avances más disruptivos de los últimos tiempos. Pero usar la IA como una herramienta extraordinaria es una cosa; atribuirle "inteligencia" real es algo muy diferente.

A menos que estemos dispuestos a relajar el término por completo (y caigamos en derivaciones laxas como inteligencia colectiva, inteligencia emocional o incluso inteligencia muscular), considero que catalogar a un LLM como inteligente es irse por las ramas.

Nadie diría jamás que Microsoft Excel es inteligente, a pesar de su abrumadora capacidad de cálculo matemático en milisegundos. ¿Por qué con los LLMs cambiamos el estándar?

A continuación, comparto mis apreciaciones técnicas sobre por qué considero que estamos ante un malentendido conceptual derivado de la escala y el lenguaje:

1. El truco de la compresión de patrones vs. La comprensión semántica.

Lo que hoy nos sorprende de los modelos modernos no es la aparición de un "ánima" o consciencia, sino el resultado de llevar el cómputo y el volumen de datos a escalas antes impensables. Al entrenar un modelo con billones de parámetros, la red neuronal no solo memoriza; genera una compresión estadística masiva de las relaciones entre las palabras escritas por la humanidad.

El sistema calcula probabilísticamente cuál es el siguiente token óptimo basándose en un contexto matemático. Resuelve problemas complejos conectando puntos distantes dentro de sus pesos ponderados, lo cual emula un proceso de razonamiento. Sin embargo, no hay introspección ni comprensión real del fondo; hay una perfecta asimilación de la forma del lenguaje.

2. El sesgo del antropomorfismo:

El "Efecto Excel" con esteroides¿Por qué nos cuesta tanto ver a la IA como vemos a una hoja de cálculo? La respuesta está en la interfaz.

Con Excel: Interactuamos mediante fórmulas y celdas rígidas. La abstracción matemática es evidente a la vista, por lo que entendemos la herramienta como un sistema puramente determinista.* Con los LLMs: La interfaz es el lenguaje humano. Estamos evolutivamente cableados para asumir que si algo nos responde usando la primera persona ("yo"), estructurando argumentos impecables y simulando empatía, obligatoriamente debe existir un sujeto consciente detrás de la pantalla.

El modelo domina el vehículo del pensamiento humano (el lenguaje), y eso nos genera la ilusión cognitiva de que también posee la esencia del pensamiento.

3. Inteligencia Colectiva Cristalizada:

El verdadero valorSi definimos la inteligencia bajo los estándares de la psicología cognitiva y la filosofía clásica —requiriendo intencionalidad, agencia propia, autoconsciencia y comprensión semántica real—, la IA generativa actual está completamente fuera de la definición.

Sin embargo, tu planteamiento sobre la inteligencia colectiva da en el clavo. Un LLM no es un ente inteligente autónomo; es un espejo estadístico del conocimiento digitalizado de millones de seres humanos. Cuando un desarrollador usa un modelo para optimizar código, no está colaborando con una entidad; está accediendo a un destilado algorítmico del pensamiento acumulado de la comunidad global. La inteligencia sigue estando del lado de quien formula la pregunta y sabe qué hacer con la respuesta; el modelo es solo una palanca cognitiva sumamente potente.

La magia sigue siendo nuestra.

Estamos ante una herramienta disruptiva y fascinante que está transformando el desarrollo de software y la educación (e-learning). Sin embargo, la verdadera hazaña tecnológica no es que las máquinas hayan aprendido a "pensar", sino que los seres humanos hayamos sido capaces de empaquetar, estructurar y comprimir nuestro propio pensamiento colectivo dentro de una arquitectura de software.

Al final del día, las redes neuronales siguen respondiendo a los mismos principios matemáticos que analizábamos hace décadas, solo que ahora cuentan con el combustible de una infraestructura de hardware monumental.

¿Cuál es tu apreciación respecto al tema? Como desarrolladores, ingenieros o investigadores, ¿creen que hemos relajado demasiado el término "inteligencia" por puro marketing, o consideran que la capacidad de resolución de problemas de los LLMs ya justifica una nueva definición? ¡Abramos el debate en los comentarios! 👇

De pájaros a pantallas: El sorprendente origen de la palabra "Chat"

Carlos Arturo Castaño G. — Sun, 04 Oct 2026 14:41:47 +0000

Como desarrolladores, pasamos una parte enorme de nuestras vidas interactuando con un "chat". Construimos aplicaciones de mensajería usando WebSockets, integramos interfaces conversacionales impulsadas por LLMs, usamos Slack o Microsoft Teams para las stand-ups diarias y miramos el chat de Twitch o YouTube cuando queremos relajarnos.

La palabra se ha vuelto tan omnipresente que ahora se utiliza incluso como un sustantivo colectivo. Los streamers se dirigen a miles de espectadores con un simple "¡Hola, chat!", y las generaciones más jóvenes ya lo usan en la vida real para hablarle a un grupo de amigos ("¿Esto es en serio, chat?").

El término se ha desgastado tanto que ha perdido su sentido original. Pero, ¿alguna vez te has preguntado de dónde salió realmente?

La respuesta no tiene absolutamente nada que ver con computadoras, código o redes: viene directamente de la naturaleza.
---## 1. El sonido de las aves (Siglo XV)Mucho antes de que existieran los protocolos de internet o los teclados, la palabra se originó como una abreviatura del verbo en inglés antiguo "chatter" (que significaba parlotear o hacer sonidos rápidos y repetitivos).

Esta palabra nació como una onomatopeya: una imitación literal del sonido agudo y constante (chat-chat-chat) que hacen los pájaros al comunicarse entre sí en los árboles.

2. De la "cháchara" a la pantalla digital (Siglos XVI al XX)

Con el paso de los siglos, los angloparlantes acortaron chatter y lo convirtieron simplemente en "chat". Dejó de aplicarse a los animales y evolucionó para describir una conversación humana informal, ligera y espontánea. Era el equivalente a lo que en español conocemos como "echar el chisme", tener una "plática casual" o hablar por hablar café de por medio.

El gran salto al ecosistema digital ocurrió en 1988. Un científico finlandés llamado Jarkko Oikarinen inventó IRC (Internet Relay Chat), el primer protocolo que permitió a personas de todo el mundo comunicarse por texto en tiempo real.

Oikarinen eligió la palabra chat deliberadamente de forma metafórica. Quería que las interacciones basadas en texto se sintieran relajadas, informales e inmediatas, marcando un fuerte contraste con la estructura lenta y formal del correo electrónico de la época.

[ Aves cantando (Chatter) ] ──> [ Plática casual (Chat) ] ──> [ Protocolo IRC (1988) ] ──> [ Interfaces Modernas / IA ]

3. El "chat" hoy: Hablándole a una mente colmena

Hoy en día, el significado ha mutado por completo. Con el auge de las plataformas de streaming, "chat" pasó de ser un verbo (una acción) a un sustantivo singular (un sujeto).

Cuando un creador de contenido mira a la cámara y dice: "¿Qué opinan, chat?", está tratando a un muro de texto que se mueve a toda velocidad, generado por miles de seres humanos individuales, como una sola entidad colectiva. Es la personificación definitiva de una interfaz digital.

En el fondo, seguimos parloteando

Irónicamente, una palabra que comenzó imitando el ruido de las aves en el bosque ahora define la forma en que la humanidad colabora, escribe código e interactúa con la Inteligencia Artificial en el siglo XXI.

La próxima vez que abras una terminal, construyas una interfaz de usuario conversacional o lances un prompt a un LLM, recuerda que en el fondo seguimos "parloteando" exactamente igual que lo hacían los pájaros hace seis siglos.

¿Y tú qué opinas? ¿Crees que la palabra "chat" ha perdido su significado real por completo o es solo la evolución natural del lenguaje dentro de la cultura tecnológica? ¡Nos leemos en los comentarios! 👇

El cifrado whatsapp funciona. Entonces, ¿por qué se filtran los chats?

Carlos Arturo Castaño G. — Wed, 30 Sep 2026 00:18:09 +0000

En Colombia se ha vuelto casi diaria la aparición de pantallazos y audios de chats de exfuncionarios, congresistas, militares y magistrados. La pregunta que más se repite es: "¿no que WhatsApp tenía cifrado de extremo a extremo?"

Lo tiene, y funciona. El problema es otro, y es un buen caso para repasar qué protege realmente el E2E y dónde está el perímetro de confianza.

Modelo de amenazas en una línea

E2E protege el canal, no los endpoints.

[Teléfono A] ══ mensaje cifrado ══> [Servidor] ══ mensaje cifrado ══> [Teléfono B]
   texto plano                    (no puede leerlo)                     texto plano
   ▲                                                                       ▲
   └── aquí ocurre casi toda la fuga ──────────────────────────────────────┘

Nadie en el camino (la empresa, el ISP, alguien interceptando la señal) puede leer el contenido. Pero en cada extremo el mensaje está en claro, y ahí el cifrado ya no aplica.

Vectores de fuga reales

Vector	¿Rompe el cifrado?	Comentario
Contraparte legítima (captura, reenvío, exportar chat)	No	Es un destinatario autorizado. Es el vector más común
Dispositivo incautado y análisis forense	No	Se lee el contenido ya descifrado en el equipo
Backups en la nube (Google Drive / iCloud)	Depende	No están cifrados E2E por defecto en WhatsApp; hay que activarlo
Sesiones vinculadas (WhatsApp Web, escritorio)	No	Una sesión olvidada expone el historial completo
Spyware tipo Pegasus	No	Lee lo que el usuario ve, directamente en el equipo
Metadatos	No aplican	Quién habla con quién, cuándo y con qué frecuencia no está cifrado

Ninguna fila requiere romper criptografía. Es ingeniería social, acceso físico o mala configuración.

Por qué salen "en cascada"

Un solo teléfono contiene decenas de conversaciones. Al obtener el dispositivo de un nodo central (un asesor, un jefe de gabinete, un militar), aparecen todos sus interlocutores. Es el equivalente a comprometer un nodo con muchas aristas en un grafo: el radio de impacto es enorme.

A eso se suma el incentivo: tras un cambio de gobierno, los antiguos aliados pasan a ser contrapartes, y entregar chats sirve como moneda de negociación.

¿Cambiar de app lo arregla?

Ayuda, pero no elimina el problema.

App	E2E	Nota
WhatsApp	Por defecto	Backups en nube sin cifrar salvo que se active
Signal	Por defecto	Menos metadatos; suele considerarse la referencia
Telegram	Solo en "chats secretos" 1 a 1	Chats normales y grupos no son E2E; quedan en servidores
Line	En texto (Letter Sealing)	Menos auditada

El error más común: creer que Telegram es "más seguro" y usar chats normales para cosas sensibles. Ahí ni siquiera hay E2E.

Y el ejemplo perfecto de que la mejor app no salva del error humano: en 2025, altos funcionarios de EE. UU. coordinaron temas militares por Signal y agregaron a un periodista por error. El cifrado funcionó bien; el fallo fue de proceso.

La autenticidad es otro problema

Una captura de pantalla se falsifica en minutos.
Un audio se puede editar o clonar con IA.
Lo que tiene valor probatorio es la extracción forense del dispositivo original con cadena de custodia, no la imagen que circula en redes.
Las filtraciones son selectivas: quien filtra decide qué y cuándo publicar, y un fragmento sin contexto puede cambiar su sentido.
Material obtenido por interceptación ilegal puede ser inadmisible como prueba, aunque sea cierto.

Checklist práctico

Activar mensajes temporales en chats sensibles.
Activar el respaldo cifrado de WhatsApp o desactivar los backups.
Revisar Dispositivos vinculados y cerrar sesiones desconocidas.
Bloqueo de pantalla fuerte y sistema operativo actualizado.
Separar dispositivos personales y de trabajo.
Regla base: no escribas por chat nada que no estés dispuesto a ver publicado, porque el otro extremo siempre puede exportarlo.

Conclusión

Como desarrolladores sabemos que un sistema es tan seguro como su eslabón más débil. Aquí el cifrado está bien implementado; lo que falla es el factor humano, la gestión de dispositivos y la configuración por defecto.

La próxima vez que alguien diga "WhatsApp no es seguro", vale la pena preguntarle qué parte del modelo de amenazas está mirando.

¿Qué otros vectores agregarían? Los leo en los comentarios.

JEV: el "modelo" que no genera texto, sino decisiones (y por qué me interesa para facturación)

Carlos Arturo Castaño G. — Wed, 23 Sep 2026 15:51:07 +0000

Cuando hablamos de IA en 2026 lo primero que se nos viene a la cabeza son los LLM conversacionales: ChatGPT, Gemini, Grok, Claude. Herramientas pensadas para generar texto, imágenes, vídeo, mantener una charla. Pero hay una categoría distinta que vale la pena conocer si programas: JEV.

¿Qué es JEV?

JEV no es un LLM convencional. No conversa, no redacta, no alucina creativamente. Es, en esencia, un asistente de toma de decisiones: dado un contexto en lenguaje natural, devuelve una respuesta dentro de un rango determinista de opciones (sí/no, una elección entre varias, un score).

La idea nace de un problema real: usar un LLM grande para tomar decisiones simples (¿esta factura es urgente?, ¿este pago es sospechoso?) funciona, pero es lento, caro y requiere bastante gestión por parte del programador — normalmente forzando al modelo a responder en JSON.

JEV ataca justo ese caso de uso.

Cómo encaja en el código

No es un chatbot ni un endpoint que "converses". Se integra en el diseño del programa como una estructura condicional más , algo parecido a un if/else o un switch/case, con la diferencia de que el criterio de decisión se le pasa en lenguaje natural en lugar de código.

Al ser determinista dentro de un rango de salidas predeterminado, no inventa respuestas nuevas ni se desvía del formato esperado. Eso lo hace mucho más fácil de integrar en un flujo de producción que un LLM generativo.

Ventajas técnicas

Velocidad: decisiones en 70–500 ms, muy por debajo de lo que tarda un LLM convencional.
Costo: del orden de $0.042 por millón de tokens de entrada, con salida gratuita — entre 4x y 7x más barato que otros modelos para este tipo de tarea.
Determinismo: no alucina ni improvisa; las respuestas están acotadas al rango de opciones definido.
Confianza: cada respuesta viene con un score de confianza, lo que permite definir umbrales para decidir qué se automatiza y qué pasa a revisión humana.

Ejemplo de integración

La llamada se hace por POST al endpoint https://api.typesafe.ai/v1/systemone, con el modelo jev-latest. Hay SDKs oficiales para Python y JavaScript.

import requests

api_url = "https://api.typesafe.ai/v1/systemone"
headers = {
    "Authorization": "Bearer TU_CLAVE_API",
    "Content-Type": "application/json"
}

invoice_data = {
    "model": "jev-latest",
    "input": {
        "context": "Factura con ID #12345 por $2,500, cliente recurrente, vencimiento en 15 días",
        "questions": [
            {
                "type": "choice",
                "question": "¿Esta factura requiere revisión manual?",
                "options": ["sí", "no"]
            },
            {
                "type": "score",
                "question": "¿Qué tan urgente es esta factura (0-10)?"
            }
        ]
    }
}

response = requests.post(api_url, json=invoice_data, headers=headers)
result = response.json()

if result["answers"][0]["choice"] == "sí":
    send_to_manual_review(invoice_id="12345")
else:
    process_automatically(invoice_id="12345")

Casos de uso en un sistema de facturación

Pensando en un backend de facturación típico, JEV podría encargarse de:

Clasificación de facturas

Detectar facturas urgentes
Clasificar por tipo de cliente (nuevo, recurrente, corporativo)
Identificar facturas con posibles inconsistencias

Procesamiento de pagos

Aprobar o rechazar pagos según criterios predefinidos
Detectar transacciones sospechosas
Decidir si un pago requiere revisión manual

Enrutamiento

Dirigir facturas a contabilidad vs. ventas
Asignar según monto o tipo de producto
Escalar a especialistas según la complejidad del caso

Lo que hay que tener presente

Privacidad: la información viaja a los servidores de TypeSafe. Con datos financieros sensibles, esto merece una evaluación cuidadosa antes de integrarlo.
No reemplaza a los LLM: JEV no compite con Claude o GPT para tareas de razonamiento complejo; los complementa. La idea es usar JEV para las decisiones rápidas y repetitivas, y dejar el LLM grande para lo que realmente requiere razonamiento.
Sin versión local o gratuita (por ahora): funciona por suscripción vía plataformas de pago. Dado lo bajo del costo, vale la pena evaluar si de todas formas compensa una alternativa local.
Documentación limitada: al ser una herramienta nueva, la información disponible todavía es escasa — vale la pena seguirle la pista.

Conclusión

Si tu sistema toma decisiones binarias o de rango acotado de forma constante , clasificar, aprobar/rechazar, enrutar , meter un LLM completo para eso es matar moscas a cañonazos. JEV apunta a llenar ese hueco: rápido, barato y determinista, pensado para vivir embebido en la lógica de la aplicación en lugar de detrás de un chat.

Más info en el blog de TypeSafe: https://typesafe.ai/blog/introducing-system-one-models-and-jev

IA para todos: Cuando la herramienta deja de ser el diferenciador

Carlos Arturo Castaño G. — Mon, 21 Sep 2026 02:13:07 +0000

"Cuando todos tienen las mismas herramientas, gana, como siempre el que hace o tiene algo distinto que lo diferencie del resto."

El privilegio de los primeros

Durante los primeros momentos de lo que ahora llamamos Inteligencia Artificial, el indicador de éxito era claro: quien tenía conocimiento, aunque fuera mínimo, dominaba el campo. Se dice que en países de ciegos el tuerto es rey, quien manejaba la herramienta tenía una ventaja significativa.

Era la época dorada donde saber usar ChatGPT o Midjourney te convertía en alguien "especial". Los cursos abundaban, los salarios se inflaban, y los early adopters disfrutaban de un mercado ávido de cualquiera que supiera pronunciar "prompt engineering".

La democratización llegó (y se quedó)

Parece que con el mundo hiperconectado y la avalancha de cursos, tutoriales y manuales sobre IA, la mayoría de las personas ya la manejan cómodamente. Como siempre, unos mejor que otros, pero en el fondo la idea más importante es que todos la manejan.

Ya no es un diferenciador. Y, por el contrario, no manejarla es ahora una gran desventaja.

Algo similar a lo que sucedió con Excel y Word: en un principio, quienes los dominaban tenían un plus; ahora, quien no los maneja está en grave desventaja laboral.

Con esta nivelación de la información, y específicamente de la IA, las aguas vuelven nuevamente a su cauce.

Los elefantes en la habitación

Aún hay temas muy serios que resolver sobre su uso:

La ética en los modelos de entrenamiento
La soberanía digital (mi tema favorito)
La gobernanza de los datos

Pero seamos honestos: esos son asuntos que, a la verdad, al común de la gente le importan poco o nada. Ya sabemos cómo funciona el mercado laboral: cuando se trata de responder a la estabilidad económica, es "vamos a lo que vinimos". Esos temas "esotéricos" para la mayoría los tienen sin cuidado.

La nueva realidad

Una vez pasado el pánico sobre la IA ,bueno, algunos aún se sienten en pánico, la realidad del día a día es que manejar IA ya no es algo novedoso que te dé algún tipo de plus.

Porque, como hemos dicho, la IA no piensa por uno. Lo que sí hace es potenciar y hacer las cosas más rápido.

⚠️ Y aquí viene el punto crucial: cuando decimos esto, estamos implicando que lo mismo vale para lo correcto y maximiza de forma exponencial los errores.

La conclusión incómoda

La herramienta ayuda, pero cuando ayuda a todos por igual, la diferencia vuelve a ser favorable a quien la use de mejor manera, como con cualquier herramienta desde el martillo hasta el compilador.

No se trata de tener acceso a la IA. Se trata de:

Qué preguntas haces
Cómo iteras sobre las respuestas
Qué criterio aplicas para validar o descartar lo que te devuelve
Cuánto conocimiento del dominio tienes para juzgar la calidad

La ventaja competitiva no está en la herramienta. Está en ti.

Volviendo (otra vez) al tema de la soberanía digital

Carlos Arturo Castaño G. — Thu, 10 Sep 2026 01:36:05 +0000

A veces uno se vuelve monotemático con ciertos asuntos. Le da vueltas y vueltas al mismo tema, no porque quiera insistir por insistir, sino porque el tema mismo vuelve a aparecer una y otra vez. En mi caso, ese tema recurrente es la soberanía digital: la idea de que las empresas y los países deberían poder usar su propia inteligencia artificial, entrenada por ellos mismos, en lugar de depender siempre de los grandes laboratorios que hoy dominan el mercado.

Existen ya muchos modelos de este tipo, listos para usarse. El problema es el costo: los servidores necesarios nunca están al nivel de los mega centros de cómputo donde se entrenan esas inteligencias artificiales para producción, y aun así siguen siendo caros. Por eso, hoy en día, solo las grandes empresas o los países con recursos pueden asumir ese reto.

Sin embargo, hay un punto intermedio que vale la pena resaltar: una empresa con un presupuesto modesto —unos 4.000 dólares, por ejemplo— puede poner a funcionar una máquina con su propia inteligencia artificial. Por supuesto, con ciertas limitaciones, pero en la práctica ese tipo de configuración puede ofrecer un desempeño más que aceptable. Y ahí está, de nuevo, mi tema recurrente.

¿Por qué vuelvo a esto ahora?

Porque el CEO de Anthropic anunció que, en sus sistemas de desarrollo, solo se pueden usar archivos markdown (*.md) propios de la compañía: específicamente, uno llamado claude.md.

A primera vista, esto suena trivial. Uno podría pensar: "pues le ponemos ese nombre al archivo y ya, problema resuelto". Pero no es tan simple. Para quien no lo sepa, un skill (en este contexto) es, resumiendo mucho, un archivo de texto con instrucciones para que la inteligencia artificial sepa cómo trabajar. Los puristas del tema podrán discrepar con esta simplificación, pero en esencia es así.

El problema es que otras inteligencias artificiales usan un archivo con otro nombre, AGENTS.md, mientras que Claude exige el suyo propio. Esto significa que, dependiendo del agente de IA que se quiera usar, habrá que mantener archivos distintos que hacen básicamente lo mismo.

Un déjà vu tecnológico

Esto me recuerda una historia ya conocida: cuando "el diablo estaba chiquito", una empresa muy asociada a un sistema operativo con ventanitas decidió hacer algo parecido con su navegador, ignorando los estándares del W3C y creando su propio camino. El resultado fue código lleno de parches, instrucciones duplicadas y páginas web que se veían bien en un navegador pero mal —o simplemente no funcionaban— en otros.

Eso es, más o menos, lo que Anthropic está proponiendo ahora con sus archivos markdown propios: vamos a necesitar distintos archivos que hacen lo mismo, dependiendo del agente de IA que usemos. De hecho, ya hay grandes empresas que han manifestado su inconformidad, porque tienen cientos o miles de estos archivos, y ahora tendrían que duplicarlos solo para que funcionen con los agentes de Anthropic.

Conclusión

Por eso insisto, una vez más, en la importancia de evitar este tipo de arbitrariedades comerciales. La soberanía tecnológica vuelve a ser, para mí, la mejor forma de evitar quedar atrapados en este tipo de "caprichos" tecnológicos impuestos por unos pocos actores del mercado.

ISO 42001 vs ISO 27001: ¿moda comercial o gobernanza real de IA?

Carlos Arturo Castaño G. — Mon, 07 Sep 2026 23:34:34 +0000

Actualmente hay mucho sobre la ISO 42001, la pregunta es si se aprovecha comercialmente y, para muchas organizaciones, parece "más de lo mismo con otro nombre". La pregunta es solo moda? o en realidad introduce controles específicos de gobernanza de IA que ISO 27001 no cubre de forma explícita. La clave está en cómo se implementa y en si ya se tiene 27001.

Qué es ISO 42001 y por qué existe

ISO/IEC 42001:2023 es el primer estándar internacional de sistema de gestión dedicado específicamente a inteligencia artificial (AIMS: AI Management System). Su propósito no es regular cada modelo de IA ni certificar que un algoritmo sea "seguro", sino exigir que la organización tenga un marco documentado para:

Definir políticas y objetivos de uso responsable de IA.
Identificar y evaluar riesgos propios de IA (sesgo, opacidad, falta de supervisión humana, impactos sociales).
Gestionar el ciclo de vida de los sistemas de IA (desde el diseño hasta el retiro).
Establecer roles, métricas de monitoreo y mecanismos de mejora continua.

En otras palabras: 27001 protege la información (confidencialidad, integridad, disponibilidad); 42001 gobierna cómo se usan sistemas de IA que toman decisiones o automatizan procesos, y cómo esos sistemas afectan a las personas.

Diferencias reales frente a ISO 27001

Aunque comparten la misma estructura de alto nivel (Anexo SL) y muchos procesos de gestión, los controles técnicos son distintos y con poca superposición directa:

ISO 27001: riesgos de seguridad de la información (brechas, accesos no autorizados, pérdida de datos). Controles típicos: gestión de accesos, cifrado, logs, seguridad de proveedores.
ISO 42001: riesgos de comportamiento de la IA (sesgo, discriminación, decisiones inexplicables, falta de supervisión humana, impactos éticos/sociales). Controles típicos: evaluación de impacto de IA, transparencia/explicabilidad, equidad, supervisión humana significativa, gestión del ciclo de vida de modelos.

Un sistema puede estar perfectamente asegurado (27001) y aun así generar decisiones discriminatorias o incomprensibles; ahí entra 42001.

¿Es una norma "comercial" o realmente necesaria?

Hay un claro aprovechamiento comercial: consultoras y firmas de auditoría están vendiendo "implementación de ISO 42001" como nuevo servicio, y algunas empresas la usan como argumento de marketing ("certificados en IA responsable").
Para organizaciones pequeñas o con uso muy limitado de IA, el costo/beneficio puede ser dudoso si ya tienen 27001 bien implementada.

Pero también hay motivos no puramente comerciales:

Regulaciones emergentes (UE AI Act, leyes locales de IA) empiezan a exigir gobernanza documentada de IA; 42001 ofrece un marco reconocido internacionalmente para demostrarlo.
Para empresas que desarrollan o integran IA en productos/servicios críticos (finanzas, salud, RR. HH., justicia), tener un AIMS certificado puede ser un diferenciador de confianza para clientes y socios.

Si ya tienes ISO 27001, ¿hay que empezar de cero?

No. De hecho, los expertos coinciden en que con 27001 ya tienes la mayor parte de la "estructura de gestión" y puedes integrar 42001 sin rehacer todo:

Reutilizas: política de gestión de riesgos, auditorías internas, revisión por la dirección, control documental, gestión de proveedores, etc.
Añades/ajustas:
- Política específica de IA y roles de gobernanza de IA.
- Evaluaciones de impacto de IA (no solo de seguridad).
- Controles de sesgo, equidad, transparencia y supervisión humana.
- Gestión del ciclo de vida de modelos (versionado, monitoreo de desempeño, retirada).

En términos de costo, tener 27001 reduce la implementación de 42001 entre 30–60%, porque la base del sistema de gestión ya está hecha.

¿Debería tu empresa actualizar a 42001 o basta con ajustar 27001?

Depende de:

Nivel de exposición a riesgos de IA: si usas IA para decisiones que afectan personas (contrataciones, crédito, diagnóstico, moderación de contenido, etc.), 42001 aporta valor real más allá de 27001.
Exigencias de clientes o regulación: si tus clientes o el marco legal empiezan a pedir gobernanza de IA certificada, 42001 te pone en regla de forma estandarizada.
Costo/beneficio interno: si tu uso de IA es limitado y ya tienes controles internos sólidos, quizás baste con extender tu ISMS con anexos/procedimientos de IA sin buscar certificación formal.

En la práctica, lo más sensato para quien ya tiene 27001 es:

Hacer un mapeo de brechas entre tu ISMS actual y los requisitos de 42001.
Implementar solo los controles adicionales de IA que realmente necesites.
Decidir si buscas certificación completa o mantienes un "AIMS interno" alineado con 42001 sin auditoría externa.

En síntesis

No es solo moda: 42001 cubre riesgos de IA que 27001 no aborda de forma específica.
Sí hay componente comercial y, para algunos, puede ser excesivo si el uso de IA es bajo.
Si ya tienes 27001, no empiezas de cero; puedes integrar 42001 con un esfuerzo adicional focalizado y significativo ahorro de costo.

Fuentes: BDO, ISO.org, UCS ISO, Schellman, TruvoCyber, DeepInspect, FinanceFeeds, CertPro

Gobernanza del Dato: El Verdadero Tesoro detrás de la IA

Carlos Arturo Castaño G. — Sat, 05 Sep 2026 20:51:41 +0000

Gobernanza del Dato: El Pilar Olvidado en la Era de la IA

Hoy en día, tanto personas naturales como jurídicas hacen un uso de la inteligencia artificial mucho más intensivo que antes, aunque no necesariamente mejor o peor. Existen innumerables tratados, cursos, foros y todo tipo de iniciativas orientadas a capacitar en el uso y manejo de la información asociada a la IA: prompts, skills, loops y un sinfín de herramientas que invitan a adentrarse en el mundo de la experiencia personal y corporativa.

Esto me parece bien, muy bien, de hecho. Algunos lo hacen con más éxito que otros, pero sin duda, después del pánico inicial y de que algunos sectores mostraran resistencia —o al menos una aceptación reticente—, poco a poco nos vamos asentando en su adopción.

La polvareda que levantó la IA

En mi caso particular, sin dejar de programar —y muchas veces a código puro, por diferentes razones: porque me gusta, porque puedo hacerlo y simplemente porque me parece más práctico en soluciones puntuales—, lentamente me he ido dando cuenta de algo que siempre existió, pero que ahora se manifiesta de manera especialmente clara.

Los datos: es, en esencia, lo que finalmente queda después de que la polvareda que ha levantado la IA se haya asentado.

Pero no se trata simplemente del dato frío y escueto; eso no aporta nada. Lo que se necesita es, si se me permite la expresión, la Gobernanza del dato. No sé si el término existe formalmente, pero suena bien; al menos la palabra "gobernanza" está muy de moda.

¿Qué implica realmente la Gobernanza del Dato?

Lo que quiero decir es que los datos no son fantasmas que aparecen y desaparecen dentro de una empresa. No son, a mi parecer —y con derecho a equivocarme—, entidades sin sustancia propia.

En esa forma de ver la sustancia de la empresa a través de sus datos, relaciones y correlaciones, se traduce la gobernanza como:

Saber de dónde viene el dato.
Qué aporta y si está actualizado o no.
Cómo se relaciona con el entorno.
Cuál es su vida útil.
Quién lo generó y para qué.
Qué realidad trata de mostrar.
Si se puede sintetizar o si es "puro" (si tiene origen en otro contexto).

En medicina existe el término vademécum, que recopila datos y nociones de diferentes áreas. Las empresas deberían tener una política similar —y si no la tienen, deberían implementarla— para saber qué implicación tiene un dato, su cálculo y su uso en las decisiones de la compañía.

Mi experiencia en el desarrollo: el 60% que lo cambia todo

En el desarrollo de mis aplicaciones, de forma inercial —no como algo buscado, sino de manera orgánica— me he dado cuenta de que el desarrollo de una aplicación se me facilita enormemente si logro indicar, ya sea a la IA, a un asistente o a mí mismo:

Cómo se relaciona un dato con el proyecto.
Qué tipo de dato es (número, etiqueta, texto, imagen).
De qué forma se enlaza con lo demás.
Si es un dato seleccionable o "puro" (en el sentido de que no se puede inferir de una selección o cálculo).

Al terminar de desplegar todos y cada uno de los datos, su morfología, su sintaxis, su estructura y su repercusión en un esquema —cosa que normalmente me toma más del 60% del tiempo de desarrollo—, la implementación de los procesos de una entidad es bastante más sencilla. Describir la topología de la estructura de los datos mediante, por ejemplo, un CRUD, es mucho más simple si se procede de esta forma.

El problema de las fórmulas "empotradas"

Mi llamado es que las empresas empiecen a pensar en la gobernanza de sus datos y en la forma en que fueron creados y gestionados. Eso, he notado —como digo, por puro desarrollo orgánico— da orden, pero también permite usarlos como una estructura para mejorar los desarrollos.

Esto es de vital importancia cuando la IA se usa —y de forma más exigente si se hace a través de agentes—.

En los procesos de sistematización, me encuentro no pocas veces creando tablas de configuración para ser llenadas con números o fórmulas "empotradas" (es decir, clavadas en un proceso) porque ya nadie en la empresa recuerda de dónde salieron o cómo se hicieron. Solo se dice:

"Siempre se ha hecho así".

Conclusión: Un llamado a la acción

La IA nos da superpoderes, pero sin una base sólida de datos, esos poderes se diluyen en caos y ruido. Invertir tiempo en documentar, estructurar y gobernar nuestros datos no es un lujo, es una necesidad estratégica.

Si logramos que las empresas comprendan que el dato es el verdadero activo, y que su gobernanza es el mapa que guía todo el desarrollo tecnológico, estaremos construyendo cimientos mucho más sólidos para el futuro.

¿Y tú? ¿Has enfrentado el problema de los datos "huérfanos" o las fórmulas heredadas en tus proyectos? Te leo en los comentarios. 🚀

Microalucinaciones: un ejemplo de un error de un día al formatear fechas en JavaScript

Carlos Arturo Castaño G. — Tue, 25 Aug 2026 23:31:18 +0000

El uso de la inteligencia artificial como herramienta de programación ofrece una ventaja evidente: rapidez.

Sin embargo, esa rapidez también exige algo que nunca deberíamos delegar completamente en una IA: la revisión y comprensión del código que vamos a llevar a producción.

Esto es especialmente importante cuando trabajamos con aplicaciones transaccionales, donde un pequeño error aparentemente insignificante puede producir consecuencias importantes.

Un error de un día en una fecha puede afectar una factura, una reserva, una vigencia, una fecha de vencimiento, un sorteo o cualquier otro proceso donde la fecha tenga significado comercial o legal.

En este artículo presento un ejemplo muy sencillo de lo que podríamos llamar una microalucinación de código: una solución que parece completamente correcta, funciona en muchas situaciones y, sin embargo, contiene un comportamiento que puede producir un error muy difícil de detectar.

El problema

Supongamos que necesitamos convertir una fecha recibida como:

2026-08-25

en:

25/08/2026

A primera vista parece una operación trivial.

Podríamos pensar que basta con crear un objeto Date y obtener el día, el mes y el año.

Pero aquí aparece una particularidad importante de JavaScript:

Una fecha calendario y una fecha-hora son conceptos diferentes.

Cuando utilizamos Date, estamos trabajando con un instante en el tiempo, y ese instante está relacionado con una zona horaria.

Cuando solamente tenemos:

YYYY-MM-DD

quizá lo que realmente tenemos no es un instante, sino simplemente una fecha de calendario.

Tres formas de resolver el problema

Veamos tres implementaciones aparentemente similares.

Opción 1: trabajar directamente con el texto

Esta implementación evita crear un objeto Date cuando recibe una fecha en formato YYYY-MM-DD.

export function formatDate(iso) {
    const s = (iso || '').toString().trim();

    let y, m, d;

    if (s.includes('-') && s.length >= 10) {
        [y, m, d] = s.slice(0, 10).split('-');
    } else if (iso instanceof Date && !isNaN(iso)) {
        y = String(iso.getFullYear());
        m = String(iso.getMonth() + 1).padStart(2, '0');
        d = String(iso.getDate()).padStart(2, '0');
    } else {
        return s;
    }

    return `${d}/${m}/${y}`;
}

Para:

formatDate("2026-08-25");

obtenemos:

25/08/2026

¿Por qué funciona?

Porque en este caso no estamos interpretando la fecha.

Simplemente estamos diciendo:

los primeros cuatro caracteres son el año;
los siguientes dos son el mes;
los últimos dos son el día.

No existe ninguna conversión de zona horaria.

Opción 2: utilizar `Date`

Ahora veamos una solución que parece igualmente correcta:

export function formatDate(dateString) {
    if (!dateString) return '';

    const date = new Date(dateString);

    if (isNaN(date.getTime())) {
        return dateString;
    }

    const day = String(date.getDate()).padStart(2, '0');
    const month = String(date.getMonth() + 1).padStart(2, '0');
    const year = date.getFullYear();

    return `${day}/${month}/${year}`;
}

A primera vista parece perfectamente razonable.

Pero aquí está el problema.

¿Qué ocurre con `new Date("2026-08-25")`?

Cuando JavaScript recibe una fecha ISO de la forma:

new Date("2026-08-25")

esa representación se interpreta como:

2026-08-25T00:00:00.000Z

Es decir, medianoche en UTC.

Ahora supongamos que ejecutamos el código en una zona horaria UTC-5.

La conversión sería aproximadamente:

UTC:
2026-08-25 00:00

UTC-5:
2026-08-24 19:00

El instante sigue siendo exactamente el mismo.

Lo que cambió fue la representación local.

Y entonces ocurre algo aparentemente absurdo:

date.getDate()

puede devolver:

cuando el texto original decía:

2026-08-25

Por eso podemos terminar mostrando:

24/08/2026

en lugar de:

25/08/2026

El detalle que hace peligroso este error

Lo interesante de este problema es que el código no falla de manera evidente.

No tenemos necesariamente:

una excepción;
un null;
un undefined;
un error en consola;
un NaN;
un fallo de ejecución.

El programa continúa funcionando.

Simplemente muestra una fecha incorrecta.

Y eso es mucho más peligroso en determinados sistemas.

Opción 3: utilizar una expresión regular

Otra solución sencilla es tratar la fecha como lo que realmente representa en este contexto: un dato textual.

export function formatDate(dateString) {
    if (!dateString) return '';

    const s = String(dateString).trim();

    const match = s.match(/^(\d{4})-(\d{2})-(\d{2})/);

    if (match) {
        const year = match[1];
        const month = match[2];
        const day = match[3];

        return `${day}/${month}/${year}`;
    }

    return s;
}

El resultado será:

25/08/2026

porque nunca se crea un objeto Date.

No hay conversión de UTC.

No hay conversión de zona horaria.

No hay posibilidad de que la fecha retroceda cinco horas.

La diferencia fundamental

Podemos resumir el problema de esta manera:

Situación	Tipo de dato	¿Conviene usar `Date`?
`2026-08-25`	Fecha de calendario	No necesariamente
`2026-08-25T14:30:00Z`	Instante en el tiempo	Sí
Timestamp Unix	Instante en el tiempo	Sí
Fecha de nacimiento	Fecha de calendario	Normalmente no
Fecha de vencimiento	Fecha de calendario	Depende del sistema
Hora de una transacción	Fecha-hora	Sí

La pregunta importante antes de utilizar Date debería ser:

¿Estoy trabajando con una fecha de calendario o con un instante en el tiempo?

¿Cómo evitar el problema?

Si solamente necesitamos transformar:

YYYY-MM-DD

DD/MM/YYYY

no necesitamos convertir el valor en un objeto Date.

Podemos utilizar split():

const [year, month, day] = dateString.split('-');

const result = `${day}/${month}/${year}`;

O una expresión regular:

const match = dateString.match(/^(\d{4})-(\d{2})-(\d{2})/);

Esto mantiene el dato como texto y evita introducir innecesariamente una zona horaria.

¿Y si realmente necesitamos utilizar `Date`?

Si el dato representa un instante y necesitamos trabajar con él, entonces Date es apropiado.

En esos casos debemos ser conscientes de la diferencia entre:

getDate()
getMonth()
getFullYear()

getUTCDate()
getUTCMonth()
getUTCFullYear()

Por ejemplo:

const date = new Date("2026-08-25");

console.log(date.getUTCDate());

puede devolver:

porque estamos consultando explícitamente la representación UTC.

Mientras que:

console.log(date.getDate());

consulta la representación en la zona horaria local.

El verdadero problema cuando usamos IA

Este ejemplo no pretende decir que la inteligencia artificial sea una mala herramienta para programar.

Todo lo contrario.

La IA puede ahorrar una enorme cantidad de tiempo.

El problema aparece cuando aceptamos una solución simplemente porque:

compila;
parece lógica;
funciona en nuestras primeras pruebas;
tiene una sintaxis correcta;
fue generada por una herramienta aparentemente confiable.

Una IA puede generar código técnicamente válido que, sin embargo, no sea correcto para el contexto específico de nuestra aplicación.

En este ejemplo, la función puede funcionar perfectamente durante semanas o meses.

Y solamente fallar cuando:

cambia la zona horaria;
el servidor está configurado en otra zona;
el usuario está en otro país;
se procesa una fecha cercana a medianoche;
se utiliza una fecha sin componente horario.

Ese tipo de errores son especialmente difíciles de encontrar.

Una microalucinación peligrosa

Podemos llamar a esto una microalucinación de programación porque la solución generada puede parecer perfectamente razonable.

El código:

const date = new Date(dateString);

es correcto desde el punto de vista sintáctico.

También es válido utilizar:

date.getDate();

El problema no está necesariamente en cada instrucción individual.

El problema está en la combinación de ambas y en el significado del dato que estamos procesando.

La IA puede no conocer, o no considerar, que en nuestra aplicación:

2026-08-25

significa simplemente:

"25 de agosto de 2026"

y no:

"el instante correspondiente a las 00:00 UTC del 25 de agosto de 2026".

Esa diferencia conceptual es la que puede producir el error.

Regla de oro

Una regla sencilla que podemos aplicar es:

Si el dato es una fecha de calendario y solamente necesitamos reorganizar sus componentes, tratémoslo como texto.

Por ejemplo:

YYYY-MM-DD

puede transformarse directamente en:

DD/MM/YYYY

sin utilizar Date.

En cambio, si tenemos:

2026-08-25T15:30:00Z

estamos trabajando con un instante concreto.

En ese caso sí debemos considerar:

UTC;
zona horaria;
hora local;
conversión de fechas;
formato de salida.

Conclusión

Este pequeño ejemplo muestra por qué revisar el código generado por inteligencia artificial no es opcional.

Un error de un día puede parecer insignificante.

Pero en una aplicación transaccional podría significar:

una factura vencida antes de tiempo;
una reserva asignada al día incorrecto;
una promoción finalizada antes de tiempo;
un pago asociado a otra fecha;
un sorteo programado para un día diferente;
una vigencia contractual incorrecta;
o cualquier otro proceso donde la fecha tenga importancia.

Lo más peligroso es que probablemente no veremos ningún error en consola.

El sistema continuará funcionando.

Simplemente estará produciendo información incorrecta.

Y precisamente por eso estos errores son difíciles de detectar.

La inteligencia artificial puede escribir código mucho más rápido que nosotros.

Pero entender qué significa ese código y verificar que corresponde al problema real sigue siendo responsabilidad del programador.

La pregunta que deberíamos hacernos

Antes de aceptar cualquier código relacionado con fechas, conviene preguntarnos:

¿Estoy manipulando una fecha de calendario o estoy manipulando un instante en el tiempo?

Esa pequeña pregunta puede evitar un bug de un día que, dependiendo del sistema, podría terminar siendo un problema mucho más grande.

Neurodivergencia en el aprendizaje de sistemas: una mirada desde la práctica

Carlos Arturo Castaño G. — Sun, 23 Aug 2026 20:13:41 +0000

Neurodivergencia en el aprendizaje de sistemas: una mirada desde la práctica

He tenido la oportunidad de conocer y trabajar con personas neurodivergentes altamente funcionales. En concreto, interactué con dos de ellas mientras aprendían funciones básicas —y luego no tan básicas— de análisis y operación de sistemas. La experiencia fue muy enriquecedora y cambió mi forma de ver el aprendizaje técnico.

Lo que más me llamó la atención

Cuando estas personas se enfocan o algo les despierta interés, son sumamente analíticas y concentradas. Detectan situaciones que a una persona neurotípica le cuestan más notar, ya sea por:

Dificultad para mantener la concentración.
Mayor capacidad para identificar discrepancias en detalles críticos que hacen que un sistema funcione bien.

Además, son muy precisos y ordenados, tanto en sus observaciones como en la ejecución de tareas.

Ejemplos concretos de tareas donde destacaron

En el día a día, noté diferencias claras en tareas como:

Revisión de logs de errores: Mientras yo pasaba por alto líneas repetitivas, ellos detectaban patrones anómalos en timestamps o códigos de error que parecían iguales pero no lo eran.
Validación de datos de entrada: Identificaban rápidamente campos mal formateados, valores fuera de rango o inconsistencias en estructuras JSON que a mí me tomaban más tiempo encontrar.
Seguimiento de flujos de trabajo: Al operar sistemas con múltiples pasos, recordaban el orden exacto y señalaban cuándo un paso se había saltado o ejecutado en secuencia incorrecta.
Optimización de procesos repetitivos: Sin que se les pidiera, proponían pequeñas mejoras, como agrupar tareas similares o eliminar pasos redundantes en la operación diaria.

Estos no eran sistemas triviales: hablo de herramientas con múltiples módulos, integraciones y reglas de negocio que normalmente requieren semanas de entrenamiento.

El factor humano: confianza y acompañamiento

Es cierto que, en ocasiones, debido a su condición, pueden sentirse inseguros o fuera de su espacio de confort. Sin embargo, si se les transmite tranquilidad y seguridad, responden muy bien.

En uno de los casos:

La madre lo acompañó durante un tiempo hasta que ganó confianza.
Una vez en ese estado, asimiló rápidamente lo que se le enseñaba.
Aprendió tan rápido que, casi sin necesidad de explicaciones extensas, intuía los siguientes pasos y qué hacía falta para optimizar el proceso.

En el otro caso, una persona más interactiva:

Con explicaciones sencillas, empezó a operar el sistema con confianza y rapidez.

Lo que más valoré fue ver cómo, una vez que se sentían seguros, preguntaban menos por miedo y más por curiosidad técnica.

Disciplina y atención superiores a la media

Lo que más destacó fue la seriedad y dedicación con que abordaron las tareas, mostrando una disciplina y atención muy superiores a la media.

Mientras yo a veces me distraía con correos o mensajes, ellos mantenían el foco en la tarea hasta completarla con precisión. No era raro verlos revisando dos o tres veces un proceso antes de darlo por terminado, asegurándose de que todo estuviera en orden.

Una reflexión final

No pretendo generalizar: sé que la neurodivergencia es compleja, requiere guías profesionales y que encauzar estos talentos no es fácil. Cada persona es única y necesita su propio ritmo y enfoque.

Pero veo una oportunidad real para que, eventualmente, estas personas:

Se integren al mundo laboral técnico.
Generen cierta independencia.
Aporten desde sus fortalezas únicas al desarrollo, operación y mejora de sistemas.

Para mí, esta experiencia fue un recordatorio de que la diversidad cognitiva no es una barrera, sino una ventaja cuando se sabe acompañar y dirigir.

¿Has tenido experiencias similares trabajando con personas neurodivergentes en entornos técnicos? ¿Qué estrategias te han funcionado para facilitar el aprendizaje? Me encantaría leer tus comentarios y aprender de tu experiencia.

Arquitectura de integración entre Web 2 y blockchain: un enfoque desacoplado

Carlos Arturo Castaño G. — Sun, 02 Aug 2026 01:52:58 +0000

Arquitectura de integración entre Web 2 y blockchain: un enfoque desacoplado

En el desarrollo de aplicaciones que combinan la web tradicional (Web 2) con funcionalidades blockchain, es común enfrentar la necesidad de generar contratos inteligentes o NFTs desde una plataforma de gestión centralizada.

Inicialmente, este tipo de procesos se manejaba de forma convencional: invocando un servidor externo (por ejemplo, con Python o Node.js), ejecutando el proceso y esperando los resultados de manera síncrona.

# Ejemplo típico de llamada síncrona
python deploy_contract.py --network ethereum --params contract_data.json

Si bien este enfoque puede funcionar en entornos controlados, presenta limitaciones importantes cuando se trabaja con blockchain:

Tiempos de confirmación variables
Posibilidad de fallos en cualquiera de las múltiples etapas del proceso
Necesidad de implementar mecanismos robustos de recuperación de errores

Problema clave: la gestión del control se vuelve más compleja que el propio objetivo de publicar información en la cadena de bloques.

El problema del acoplamiento directo

En una arquitectura típica, coexisten dos sistemas fundamentalmente independientes:

Sistema	Características
Web 2	Servidores, bases de datos, lenguajes convencionales, arquitectura backend/frontend completa
Blockchain	Protocolos propios, tiempos de confirmación variables, modelos de consenso, ejecución de contratos inteligentes

Cuando se intenta conectar ambos sistemas mediante llamadas directas (es decir, invocando funciones blockchain desde la aplicación Web 2), se genera un acoplamiento estrecho que obliga al sistema principal a gestionar:

Reintentos automáticos
Manejo de excepciones específicas de blockchain
Sincronización de estados
Validación de transacciones

La solución: desacoplamiento mediante un patrón de cola (spooler)

La mejor práctica en este tipo de escenarios es desacoplar los procesos. Para ello, se propone una arquitectura basada en tres componentes clave:

1. Definición clara de procesos blockchain

Se identifican y documentan los procesos que requieren interacción con la blockchain:

Creación de contratos inteligentes
Emisión de NFTs
Actualización de estados en la cadena

Cada proceso se diseña para responder de manera uniforme a operaciones CRUD (crear, leer, actualizar, borrar), siguiendo patrones convencionales de desarrollo.

# Ejemplo de definición de proceso
class BlockchainProcess:
    def create(self, params): pass
    def read(self, id): pass
    def update(self, id, params): pass
    def delete(self, id): pass

2. Gestor independiente de contratos y NFTs

Se desarrolla un módulo especializado, completamente desacoplado del sistema Web 2, encargado de gestionar la lógica blockchain.

# Gestor independiente con pruebas unitarias
class ContractManager:
    def deploy_contract(self, contract_data):
        # Lógica específica de blockchain
        return contract_id

    def mint_nft(self, nft_data):
        # Lógica específica de NFT
        return nft_id

Este módulo incluye:

✅ Pruebas unitarias
✅ Pruebas de integración
✅ Validación con variables de prueba conocidas

3. Spooler (cola de mensajes)

Se implementa una cola o spooler donde la aplicación Web 2 deposita las solicitudes de procesamiento blockchain.

{
  "request_id": "uuid-12345",
  "process_type": "deploy_contract",
  "payload": { ... },
  "status": "pending",
  "created_at": "2026-08-01T10:00:00Z"
}

Una vez que la solicitud se almacena en el spooler, la aplicación Web 2 queda liberada de cualquier responsabilidad sobre el proceso.

Flujo de procesamiento asíncrono

El sistema completo opera mediante los siguientes pasos:

sequenceDiagram
    participant Web2 as Aplicación Web 2
    participant Spooler as Cola (Spooler)
    participant Worker as Microservicio Blockchain
    participant Chain as Blockchain

    Web2->>Spooler: 1. Deposita solicitud
    Web2-->>Web2: 2. Continúa su ejecución
    Worker->>Spooler: 3. Monitorea nuevas solicitudes
    Worker->>Chain: 4. Procesa en la blockchain
    Chain-->>Worker: 5. Retorna resultado (ID, estado)
    Worker->>Spooler: 6. Actualiza estado
    Worker->>Web2: 7. Notifica resultado
    Web2->>Web2: 8. Actualiza procesos en espera

4. Servicio de procesamiento asíncrono

Un microservicio monitorea el spooler y, al detectar nuevas solicitudes, las procesa utilizando la lógica blockchain correspondiente.

# Worker que procesa la cola
async def process_queue():
    while True:
        requests = await spooler.get_pending_requests()
        for req in requests:
            result = await contract_manager.process(req)
            await spooler.update_status(req.id, result)
            await notify_web2(req.id, result)

Este servicio opera en los tiempos y condiciones propios de la blockchain, sin afectar el rendimiento del sistema principal.

5. Actualización de estados y notificación

El microservicio actualiza el spooler con los resultados del procesamiento:

ID del contrato o NFT creado
Variables de control
Estado de la transacción (pending, confirmed, failed)

Posteriormente, notifica a la aplicación Web 2, que actualiza los procesos que habían quedado en espera.

Beneficios de esta arquitectura

Este enfoque, que puede considerarse una API asíncrona entre Web 2 y DApp (blockchain), ofrece varias ventajas:

Beneficio	Descripción
Desacoplamiento	Cada sistema se ocupa de lo suyo: Web 2 gestiona la interfaz y lógica de negocio; blockchain se encarga de contratos e inmutabilidad
Resiliencia	Los fallos en la blockchain no afectan la disponibilidad del sistema principal. Las solicitudes pueden reintentarse automáticamente
Escalabilidad	El microservicio de procesamiento puede escalarse independientemente según la demanda
Mantenibilidad	Al separar responsabilidades, el código es más fácil de entender, probar y mantener
Trazabilidad	El spooler permite auditar todas las solicitudes y sus estados en cualquier momento

Consideraciones adicionales

Manejo de errores

try:
    result = await contract_manager.deploy_contract(data)
    await spooler.update_status(request_id, {"status": "success", "result": result})
except BlockchainError as e:
    await spooler.update_status(request_id, {"status": "failed", "error": str(e)})
    # El worker puede reintentar automáticamente según política definida

Monitoreo y alertas

Implementar logs estructurados para cada solicitud
Configurar alertas cuando el spooler acumule muchas solicitudes pendientes
Monitorear tiempos de procesamiento promedio

Seguridad

Validar y sanitizar todos los datos antes de enviarlos a la blockchain
Implementar autenticación entre el microservicio y la aplicación Web 2
Usar variables de entorno para credenciales y claves privadas

Conclusión

La arquitectura propuesta sigue un patrón similar al de las API tradicionales (frontend → API → backend), pero adaptado a la integración entre Web 2 y blockchain.

No te puedo enseñar IA (pero sí te puedo enseñar a pensar en procesos)

Carlos Arturo Castaño G. — Sun, 26 Jul 2026 23:44:13 +0000

Hace unos días, en una fiesta, una señora se me acercó angustiada. Me dijo, casi disculpándose, que la tecnología la estaba dejando atrás. Que todo el mundo hablaba de inteligencia artificial, que sentía que el tren ya había pasado y ella seguía en el andén.

Le respondí algo que llevo años pensando y que hoy quiero compartir con calma, porque creo que le sirve a mucha más gente de la que cabe en una conversación de fiesta.

Le dije: no te puedo enseñar inteligencia artificial. Y no porque sea difícil, sino porque eso no se enseña. Lo que se enseña —y lo que en realidad necesitas— es otra cosa, mucho más antigua y mucho más tuya de lo que crees.

La calculadora no nos hizo peores matemáticos

Hace muchas décadas existían las reglas de cálculo y las tablas de logaritmos. Con eso se diseñaban puentes, se calculaban órbitas, se hacía ingeniería seria. Cuando llegó la calculadora de bolsillo, hubo ingenieros que la vieron con desconfianza: "si dejas que la máquina calcule, pierdes el entendimiento profundo".

Tenían razón a medias. Sí, se perdió cierta destreza manual. Pero se ganó algo mucho más grande: la capacidad de resolver problemas que antes eran impensables por el tiempo que tomaban a mano.

Lo mismo pasó cuando el procesador de texto reemplazó a la máquina de escribir. No solo escribimos más rápido — cambió cómo pensamos mientras escribimos. Con máquina de escribir tenías que pensar la frase completa antes de teclear, porque corregir era costoso. Con un computador puedes escribir en flujo, corregir sobre la marcha, reordenar ideas sin volver a copiar la hoja entera.

En ningún caso el cambio fue malo. Fue traumático para algunos, sí. Pero nos dio un impulso.

Con la inteligencia artificial está pasando exactamente lo mismo, solo que en un ciclo mucho más rápido y mucho más ruidoso.

El ruido que no ayuda

Y aquí está el problema: alrededor de ese cambio real se ha montado un negocio de pánico. Cursos que prometen que si no te inscribes ya, te vas a quedar sin trabajo. Escuelas que venden angustia empaquetada en doce clases. Es el mismo modelo de negocio de siempre —vender miedo urgente— solo que ahora el protagonista es la IA en vez de "hazte rico trabajando desde casa".

Ese ruido no resuelve nada. Solo lucra del roce entre las personas y una herramienta que, en el fondo, no es tan complicada de entender si alguien te la explica bien, sin prisa y sin querer venderte algo.

Lo que sí es enseñable

Volviendo a la señora de la fiesta: le dije que no le podía enseñar IA, pero tampoco le podía enseñar a pensar — eso ya lo sabe hacer, lleva toda una vida haciéndolo. Lo que sí le podía enseñar es a estructurar su pensamiento en procesos claros.

¿Qué quiere decir esto en la práctica? Que antes de pedirle algo a una herramienta de IA, vale la pena hacerse tres preguntas sencillas:

¿Qué tengo? (la información o el problema de partida)
¿Qué necesito? (el resultado que busco, lo más concreto posible)
¿Cómo sabré que está bien? (cómo voy a revisar lo que me entreguen)

Eso no es "aprender inteligencia artificial". Es lo que cualquier persona ordenada hace toda su vida para resolver un problema: organizar antes de actuar. La diferencia es que ahora, si organizas bien esas tres preguntas, tienes un interlocutor —la IA— que te puede ayudar muchísimo más rápido que antes. Y si las tienes desordenadas, la IA también te lo va a devolver desordenado.

El talante correcto

No hay que tenerle miedo al cambio. El cambio es bueno, aunque a veces duela. La calculadora, el procesador de texto, y ahora la inteligencia artificial, no vinieron a quitarnos algo — vinieron a correr la línea de lo que podemos hacer un poco más lejos.

Lo único que sí pido, y esto es importante: no confundas el entusiasmo por el cambio con fe ciega. La regla de cálculo no te mentía con confianza. Una herramienta de IA sí te puede dar una respuesta que suena perfecta y no lo es. Por eso, junto con perder el miedo, hay que ganar el hábito de revisar. Ese es el verdadero "talante": ni pánico, ni entrega total. Curiosidad, con los ojos abiertos.

A la señora de la fiesta no le hizo falta un curso. Le hizo falta que alguien le dijera, sin venderle nada, que lo que ya sabe hacer —pensar con orden— sigue siendo lo más valioso que tiene.

DEV Community: Carlos Arturo Castaño G.

¿Por qué llamarle "Inteligencia" a un LLM es un extremo estadístico? Una perspectiva tras décadas en redes neuronales.

1. El truco de la compresión de patrones vs. La comprensión semántica.

2. El sesgo del antropomorfismo:

3. Inteligencia Colectiva Cristalizada:

La magia sigue siendo nuestra.

De pájaros a pantallas: El sorprendente origen de la palabra "Chat"

2. De la "cháchara" a la pantalla digital (Siglos XVI al XX)

3. El "chat" hoy: Hablándole a una mente colmena

En el fondo, seguimos parloteando

El cifrado whatsapp funciona. Entonces, ¿por qué se filtran los chats?

Modelo de amenazas en una línea

Vectores de fuga reales

Por qué salen "en cascada"

¿Cambiar de app lo arregla?

La autenticidad es otro problema

Checklist práctico

Conclusión

JEV: el "modelo" que no genera texto, sino decisiones (y por qué me interesa para facturación)

¿Qué es JEV?

Cómo encaja en el código

Ventajas técnicas

Ejemplo de integración

Casos de uso en un sistema de facturación

Lo que hay que tener presente

Conclusión

IA para todos: Cuando la herramienta deja de ser el diferenciador

El privilegio de los primeros

La democratización llegó (y se quedó)

Los elefantes en la habitación

La nueva realidad

La conclusión incómoda

Volviendo (otra vez) al tema de la soberanía digital

¿Por qué vuelvo a esto ahora?

Un déjà vu tecnológico

Conclusión

ISO 42001 vs ISO 27001: ¿moda comercial o gobernanza real de IA?

Qué es ISO 42001 y por qué existe

Diferencias reales frente a ISO 27001

¿Es una norma "comercial" o realmente necesaria?

Si ya tienes ISO 27001, ¿hay que empezar de cero?

¿Debería tu empresa actualizar a 42001 o basta con ajustar 27001?

En síntesis

Gobernanza del Dato: El Verdadero Tesoro detrás de la IA

Gobernanza del Dato: El Pilar Olvidado en la Era de la IA

La polvareda que levantó la IA

¿Qué implica realmente la Gobernanza del Dato?

Mi experiencia en el desarrollo: el 60% que lo cambia todo

El problema de las fórmulas "empotradas"

Conclusión: Un llamado a la acción

Microalucinaciones: un ejemplo de un error de un día al formatear fechas en JavaScript

El problema

Tres formas de resolver el problema

Opción 1: trabajar directamente con el texto

¿Por qué funciona?

Opción 2: utilizar Date

¿Qué ocurre con new Date("2026-08-25")?

El detalle que hace peligroso este error

Opción 3: utilizar una expresión regular

La diferencia fundamental

¿Cómo evitar el problema?

¿Y si realmente necesitamos utilizar Date?

El verdadero problema cuando usamos IA

Una microalucinación peligrosa

Regla de oro

Conclusión

La pregunta que deberíamos hacernos

Neurodivergencia en el aprendizaje de sistemas: una mirada desde la práctica

Neurodivergencia en el aprendizaje de sistemas: una mirada desde la práctica

Lo que más me llamó la atención

Ejemplos concretos de tareas donde destacaron

El factor humano: confianza y acompañamiento

Disciplina y atención superiores a la media

Una reflexión final

Arquitectura de integración entre Web 2 y blockchain: un enfoque desacoplado

Arquitectura de integración entre Web 2 y blockchain: un enfoque desacoplado

El problema del acoplamiento directo

La solución: desacoplamiento mediante un patrón de cola (spooler)

1. Definición clara de procesos blockchain

2. Gestor independiente de contratos y NFTs

Opción 2: utilizar `Date`

¿Qué ocurre con `new Date("2026-08-25")`?

¿Y si realmente necesitamos utilizar `Date`?