DEV Community: Carlos Arturo Castaño G.

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.

Programar no pasa de moda: por qué la claridad importa más que la sintaxis

Carlos Arturo Castaño G. — Fri, 24 Jul 2026 19:09:42 +0000

Programar no pasa de moda: por qué la claridad importa más que la sintaxis

Sigue la polémica: ¿es necesario aprender a programar? ¿Debe hacerlo quien trabaja en backend, frontend o integra con APIs?

La verdad es que programar nunca pasará de moda, porque programar no es solo escribir programas de computador. Programar es tener una idea clara de los procesos necesarios para realizar una tarea, ya sea dentro de un computador o en la vida cotidiana.

Programar es pensar en procesos

Los programadores siempre han sido y serán necesarios. Lo que cambia —y está cambiando ahora— es la forma en que los programadores le dan órdenes a la máquina.

Cada cierto tiempo surgen nuevos lenguajes y métodos para comunicarse con el computador, porque existen distintos propósitos: manipular imágenes, audio, video o procesar transacciones bancarias, por ejemplo. No todos los lenguajes sirven para lo mismo; cada uno se diseñó pensando en un objetivo concreto.

Aunque, en teoría, con cualquier lenguaje se puede hacer casi todo, en la práctica no siempre es eficiente. Es como usar herramientas de mano: puedes clavar con un martillo, un destornillador o una piedra y eventualmente lograrás algo, pero no siempre con eficiencia. Por eso existen diferentes herramientas.

Cada tarea pide una herramienta

En programación ocurre lo mismo: no es igual crear software para edición de imágenes que para gestionar transacciones financieras. Cada tarea suele tener los lenguajes, marcos y herramientas que mejor se ajustan al fin perseguido.

Hoy los programadores usan inteligencia artificial para que traduzca lo que dicen en su lengua natural a un lenguaje de computador, o para que el sistema explique qué debe hacer. A ese conjunto de tecnologías y componentes —bases de datos, sistema operativo, protocolos, modelos de comunicación, entre otros— se le llama stack.

Antes se usaba más el término framework, que agrupaba modelos y librerías que indicaban a un lenguaje cómo comportarse. Y siempre ha habido múltiples opciones según el lenguaje y el propósito.

La novedad está en la interfaz

¿Qué se vislumbra en el futuro? Que cualquier persona, con o sin conocimientos profundos de lenguajes de programación, pueda indicarle a un sistema lo que debe hacer usando lenguaje natural.

Sin embargo, la IA no adivina lo que no le explicas: si no sabes lo que quieres, la IA no lo sabrá. Por eso, tener claridad sobre los procesos involucrados en una necesidad específica permite pedirle a una IA que convierta esa idea en realidad.

Hay un truco: si le das instrucciones imprecisas a la IA, obtendrás resultados imprecisos. En programación se dice: si no sabes para dónde vas, llegarás a cualquier parte. Con la IA esto es más cierto que nunca.

Pensamiento claro, resultados mejores

Ahora se pueden dar instrucciones en lenguaje natural; esto no es totalmente nuevo —ya existían lenguajes más estructurados desde los años 60—, pero la novedad es que ya no es necesario formular instrucciones tan rígidas.

No obstante, el pensamiento debe seguir siendo estructurado: si quieres algo de calidad, necesitas descomponerlo en pasos concretos. Por eso han surgido prácticas como el diseño de prompts, los bucles de refinamiento y otras técnicas que estructuran el pensamiento en tareas claras y precisas, recuperando muchos principios de la programación estructurada.

Usar prompts, loops u otras herramientas para comunicarse con una IA ayuda a organizar la idea y presentarla de forma coherente, lo cual, si se hace con cuidado, produce resultados satisfactorios.

Conclusión

En definitiva, siempre será necesario que quien "programa" —o quien indica a la IA qué hacer— tenga lucidez y claridad para transmitir sus necesidades de forma precisa.

Igual que cualquier profesional que encarga una tarea: si no entrega instrucciones claras, el resultado será deficiente.

Por eso, quizá dentro de no mucho tiempo no será imprescindible conocer la sintaxis de un lenguaje de programación, pero sí será necesario aprender a expresar ideas con claridad. En ese futuro tendrá gran valor la formación en pensamiento lógico, dialéctica, redacción, sintaxis y todas las habilidades que ayudan a transmitir ideas de forma clara, precisa y coherente.

IA en la nube vs. local: ¿realmente puedes elegir?

Carlos Arturo Castaño G. — Thu, 23 Jul 2026 18:53:51 +0000

En un artículo anterior, hablaba sobre la dicotomía que enfrentamos al decidir dónde ejecutar nuestros modelos de IA: ¿en la nube o en infraestructura local?

Señalé que la decisión gira, en gran medida, en torno a dos factores críticos:

Control de costos
Protección de datos

Y esto sigue siendo cierto. Pero hoy quiero profundizar en un matiz que complica esta elección desde la trinchera de la ingeniería y la gestión administrativa.

El precio de tener el control

Tener un servidor local no es solo comprar un equipo. Es asumir toda una cadena de costos ocultos que muchas veces no se consideran en el presupuesto inicial:

Racks y sistemas de refrigeración
Gabinetes eléctricamente aislados
Cableado estructurado
Mantenimiento físico y actualizaciones

Solo en infraestructura básica, el desembolso inicial puede superar fácilmente los 4.000 USD, dependiendo de las exigencias de rendimiento.

Y el problema no termina ahí. Compartir datos que deben protegerse —algo cada vez más común— encarece aún más la operación, porque las soluciones de seguridad y cumplimiento normativo suman capas de complejidad y gasto.

La conclusión es incómoda pero real: mantener el control total es deseable, pero no siempre está al alcance del bolsillo empresarial.

La alternativa que está ganando terreno: las "factory IA"

Cuando el coste de la infraestructura propia es prohibitivo, surge una opción intermedia que cada vez se menciona más en círculos tecnológicos: las infraestructuras compartidas, también conocidas como "factory IA".

No son data centers tradicionales. Su enfoque no es el almacenamiento masivo de datos, sino ejecutar modelos de lenguaje (LLM) ya probados y listos para consumo empresarial.

Empresas con suficiente capital intelectual y financiero montan estas fábricas de IA y ofrecen acceso a modelos maduros como:

Mistral
Llama
Qwen

Estos modelos se entregan listos para funcionar en servidores potentes, aunque no necesariamente masivos. Y al ser servicios de uso intensivo pero compartido, los precios resultan mucho más manejables.

¿No pagamos ya por IA en la web?

Es cierto. Hoy cualquiera paga por acceso a ChatGPT, Claude o Gemini. Pero el problema de fondo no es el precio por token, sino la soberanía digital.

La soberanía digital no es solo independencia política, sino la capacidad de decidir dónde se alojan los datos, cómo se procesan, quién los controla y a qué costo.

No todos los países, incluso con buen desarrollo tecnológico, pueden crear, capacitar y mantener las enormes infraestructuras necesarias para entrenar modelos desde cero. Pero sí pueden —con apoyo adecuado— ofrecer acceso a modelos ya entrenados, configurados para casos de uso locales.

El rol del Estado y las políticas públicas

Crear una factory IA no es algo que cualquier empresa pueda hacer por sí sola. Requiere:

Grandes inversiones iniciales
Personal altamente calificado
Apoyo estatal para su creación y operación

El Estado debe facilitar incentivos fiscales, marcos regulatorios claros y condiciones que permitan a las empresas invertir en este tipo de infraestructura sin quedar en desventaja frente a los gigantes tecnológicos internacionales.

Sin un impulso público, la palabra "soberanía" queda vacía.

¿Qué pasa si no actuamos?

Me atrevo a hacer una comparación: lo que ocurrió con la expansión de Internet.

Hoy, quien no tiene buena cobertura de red está en desventaja competitiva. Lo mismo pasará con las factory IA. Los países que no construyan una infraestructura adecuada para el procesamiento de IA quedarán rezagados, mientras otros avanzan y consolidan su ventaja.

Conclusión

La dicotomía nube vs. local no se resuelve con una fórmula única. Depende del tamaño de la empresa, del tipo de datos que maneja y del presupuesto disponible.

Pero lo que está claro es que la soberanía digital no puede ser un lujo solo para unos pocos. Las factory IA representan una vía realista para que países y regiones con menos recursos puedan competir en la nueva economía del conocimiento.

La pregunta no es si debemos optar por una u otra, sino cómo podemos construir un ecosistema que permita elegir con soberanía.

¿Tú qué opinas? ¿Has considerado migrar a infraestructura local o compartida? Te leo en los comentarios. 👇

La IA no adivina lo que no pensaste: el 5% que siempre falla

Carlos Arturo Castaño G. — Mon, 20 Jul 2026 17:56:40 +0000

La IA no adivina lo que no pensaste: el 5% que siempre falla

En los últimos meses se repite una idea peligrosa: “con IA ya no te equivocas”.

La realidad, después de usarla de forma intensiva en proyectos reales, es mucho más simple:

Si no pensaste algo, la IA no lo va a adivinar.

Y si lo adivina, no significa que sea correcto.

La IA acelera el desarrollo, pero no sustituye el criterio.

🧠 La ilusión de la “decisión asistida”

Las herramientas de IA actuales son muy buenas para:

Generar código
Repetir patrones
Completar estructuras
Ajustar implementaciones existentes

Pero fallan —y siempre fallarán— en algo clave:

crear intención donde no existe.

Si al diseñar un sistema no pensaste en:

la evolución del endpoint
un caso de uso futuro
una validación de negocio
un cambio de requerimientos

...la IA no puede suplir esa ausencia.

⚖️ El 95 % funciona, el 5 % aparece después

En la práctica, ocurre esto:

El sistema se genera correctamente (95 %), si fue bien concebido y se le dieron:
- los parámetros y contexto correcto
- las herramientas adecuadas
- las proyecciones y límites claros
- los tests que debe cumplir
- las reglas del negocio de forma clara y precisa
Al probar o usar, aparecen ajustes

No porque la IA “falló”.

Sino porque el requisito no existía aún.

Ese 5 % no es un bug de IA.

Es pensamiento tardío.

Y eso es normal en ingeniería.

🛠️ Por qué más herramientas no solucionan esto

Editores con IA (Cursor, Copilot, Claude Code, etc.):

Editan más rápido
Refactorizan mejor
Ahorran trabajo mecánico

Pero no mejoran la toma de decisiones.

Cambian el cómo escribes código,

no el qué deberías haber diseñado.

🔑 La regla fundamental

La IA amplifica lo que ya sabes pensar.

Si tu punto de partida es cero, el resultado sigue siendo cero.

La IA no reduce el error conceptual.

Solo acelera su materialización.

🧩 Conclusión

La IA es una herramienta excelente para ejecutar ideas.

Pero las ideas siguen siendo responsabilidad humana.

Usarla bien no consiste en delegar el pensamiento,

sino en llegar al código con algo que ejecutar.

Porque al final:

la decisión correcta no se genera,

se piensa.

🚀 ¿Te ha pasado? Cuéntame en los comentarios cómo estás usando IA en tus proyectos.

DEV Community: Carlos Arturo Castaño G.

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

3. Spooler (cola de mensajes)

Flujo de procesamiento asíncrono

4. Servicio de procesamiento asíncrono

5. Actualización de estados y notificación

Beneficios de esta arquitectura

Consideraciones adicionales

Manejo de errores

Monitoreo y alertas

Seguridad

Conclusión

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

La calculadora no nos hizo peores matemáticos

El ruido que no ayuda

Lo que sí es enseñable

El talante correcto

Programar no pasa de moda: por qué la claridad importa más que la sintaxis

Programar no pasa de moda: por qué la claridad importa más que la sintaxis

Opción 2: utilizar `Date`

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

¿Y si realmente necesitamos utilizar `Date`?