La IA no elimina la necesidad de criterio experto; la amplifica

Hay una frase que llevo meses repitiéndome. Antes necesitábamos mucho conocimiento para producir buenos documentos. Hoy seguimos necesitando ese conocimiento, pero por otro motivo: para saber si esos documentos, por impecables que parezcan, son realmente buenos.

El cambio puede parecer pequeño. En realidad, altera lo que significa ser un buen profesional.

Cada vez reviso más arquitecturas, especificaciones funcionales, presupuestos, propuestas y planes de proyecto que tienen un aspecto excelente. Están bien redactados, ordenados y llenos de decisiones que parecen razonables. Hace pocos años, preparar algo así podía llevar días. Ahora aparece en una pantalla en cuestión de minutos.

La noticia es extraordinaria. Utilizo inteligencia artificial prácticamente todos los días y trabajo mejor gracias a ella. Me permite explorar alternativas, sintetizar información, preparar un primer borrador y dedicar más tiempo a los problemas que merecen atención. Sería absurdo negar lo que aporta.

Lo que me preocupa aparece después, cuando dejamos de hablar del documento y pasamos a las decisiones. ¿Por qué se eligió esta solución? ¿Qué alternativas se descartaron? ¿Qué riesgo se aceptó? ¿Qué ocurrirá si cambia el negocio o el volumen de usuarios se multiplica por diez?

En ese momento, la calidad de la prosa ya no ayuda demasiado. Hace falta comprender el camino que llevó hasta cada decisión y asumir sus consecuencias.

La inteligencia artificial no elimina la necesidad de criterio experto. La amplifica.

El mecanismo es bastante sencillo. La IA reduce el coste de producir una respuesta, multiplica la cantidad de material que podemos generar y mejora su apariencia. Eso obliga a revisar más, dificulta distinguir qué razonamiento hay detrás y permite que un error avance con mayor rapidez. Cuanto mayores sean las consecuencias de una decisión equivocada, más valor adquiere el criterio.

Esta es una tesis profesional sobre decisiones de impacto, no una ley universal demostrada para cualquier tarea. Parte de una observación concreta: cuando producir una propuesta cuesta menos, la capacidad de comprobarla y responder por ella pasa a concentrar una parte mayor del valor.

De ahí sale una regla práctica: una propuesta de IA no debería convertirse en una decisión de impacto hasta que el equipo responsable haya podido contrastarla, documentar sus límites y asumir sus consecuencias.

Después de más de veinte años trabajando en plataformas y proyectos tecnológicos, he aprendido que los problemas importantes rara vez aparecen porque falte documentación. Aparecen cuando se toma una mala decisión demasiado pronto y nadie la cuestiona a tiempo. La IA acelera la producción de documentos, pero no corrige por sí sola ese mecanismo. Si se utiliza sin criterio, incluso puede hacer que una mala decisión llegue antes y mejor presentada.

El análisis que no resistió las preguntas

Hace unas semanas me enviaron un análisis para incorporar una funcionalidad basada en IA dentro de una plataforma. A primera vista parecía completo. El problema no era la intención de quienes lo habían preparado, sino el encargo: lo habían asumido perfiles que no debían realizar solos un análisis técnico de esa naturaleza.

Al leerlo, empecé a plantear preguntas. Quise saber cómo se había resuelto la observabilidad de la solución, cómo escalaría al crecer el uso y qué infraestructura sería necesaria para operarla con garantías. Pregunté por la disponibilidad, el seguimiento de costes, las integraciones, la protección de los datos y la respuesta ante fallos. También pedí que explicaran por qué se había elegido aquella tecnología, qué alternativas se habían descartado y quién mantendría el sistema una vez en producción.

Fui haciendo las preguntas una tras otra. Nadie pudo responderlas porque el análisis no había contemplado esas cuestiones. Lo que detecté iba más allá de una lista de apartados ausentes: el documento describía una funcionalidad, pero no había analizado la solución necesaria para construirla y operarla.

Incorporar todo lo que faltaba cambiaba la propuesta de raíz. El plazo ya no podía ser el mismo. El presupuesto era distinto. La arquitectura debía replantearse y era posible que también cambiasen la tecnología y las herramientas. Lo que se había presentado como una solución bastante avanzada seguía estando en una fase inicial de definición.

Ese es el punto en el que el criterio experto se vuelve visible. Mi aportación consistió en hacer las preguntas que faltaban, detectar las incoherencias y distinguir entre una idea atractiva y una solución que pudiera ponerse en producción.

Abrir la imagen a tamaño completo

La IA puede preparar un texto convincente a partir de información incompleta. Esa capacidad es útil cuando el texto se toma como punto de partida. Se vuelve peligrosa cuando el acabado del documento hace olvidar que aún faltan decisiones.

El modelo puede producir una respuesta bien estructurada, pero eso no garantiza que haya interpretado bien la petición ni que el resultado sea correcto. El equipo todavía debe contrastar la información, preguntar por los casos límite, identificar las dependencias y decidir si la recomendación sirve para ese contexto concreto.

Una mala decisión no deja de serlo porque esté bien redactada. Ahora, además, puede llegar a producción mucho más deprisa.

La apariencia de competencia

Estamos viviendo una especie de inflación del conocimiento. La IA ha hecho mucho más fácil producir documentos técnicamente convincentes y, por eso, su acabado dice cada vez menos sobre cuánto entiende quien los presenta.

No lo digo con desprecio hacia quien empieza. La IA abre una puerta valiosa: permite que una persona sin años de práctica obtenga antes una primera aproximación razonable, conozca el vocabulario de un campo y formule preguntas que quizá no habría sabido plantear. Un estudio con agentes de atención al cliente encontró mejoras medias de productividad cercanas al 15 %, con beneficios mayores entre quienes partían de niveles más bajos de experiencia y rendimiento.

Ese avance no convierte el resultado en conocimiento propio. Una persona puede leer una arquitectura y entender cada frase sin haber desarrollado todavía la capacidad de diseñarla. Puede explicar una recomendación mientras la conversación permanece dentro del guion. La diferencia aparece cuando cambia una restricción, surge una contradicción o alguien pide justificar el coste de una decisión.

La experiencia profesional no consiste solo en recordar respuestas. Incluye, en buena medida, reconocer qué pregunta falta, qué detalle puede romper la solución y qué compromiso será difícil de sostener dentro de dos años. Es conocimiento explícito, pero también memoria de proyectos, errores, conversaciones y consecuencias que no caben en una plantilla.

Por eso el acabado de una respuesta puede producir una ilusión extraña. Como el documento parece propio de un experto, quien lo ha generado puede sentir que domina el asunto mejor de lo que realmente lo domina. No hace falta mala fe. Basta con confundir familiaridad con capacidad.

La IA democratiza la producción de resultados, pero no proporciona por sí sola el criterio necesario para evaluarlos.

Puede ayudar a construirlo, pero no lo entrega de forma automática. Exige práctica, contraste y responsabilidad sobre decisiones reales.

Por qué la fluidez se confunde con comprensión

Hablar de falsa competencia exige un matiz. La IA no empeora a todas las personas ni genera el mismo efecto en cualquier tarea. Bien utilizada, puede ampliar la capacidad de un profesional, acelerar su aprendizaje y ofrecerle un interlocutor con el que contrastar ideas. El riesgo aparece cuando la fluidez de la respuesta sustituye a la comprobación.

Un estudio con trabajadores del conocimiento observó que quienes decían confiar más en la IA también declaraban ejercer menos el pensamiento crítico. Además, parte del trabajo intelectual se desplazaba hacia la verificación de la información, la integración de la respuesta y la supervisión de la tarea. Eso no demuestra que confiar en la IA reduzca el pensamiento crítico, pero sí señala una relación que conviene vigilar cuando diseñamos cómo se utiliza.

La tentación es comprensible. Revisar exige más energía que aceptar. Cuestionar un resultado bien escrito puede parecer una pérdida de tiempo, sobre todo cuando hay presión por entregar. Si el equipo premia la cantidad de documentos, funcionalidades o análisis terminados, la primera respuesta razonable suele ganar por agotamiento.

Así aparece el falso empoderamiento: una sensación de dominio que excede la comprensión real. Una arquitectura generada en pocos minutos hace que alguien se sienta capaz de tomar decisiones arquitectónicas. Una especificación completa crea la impresión de que el negocio ya está entendido. Un presupuesto coherente parece una evaluación de riesgos, aunque solo sea una suma de supuestos sin validar.

El problema no está en utilizar ayuda. Todos trabajamos apoyados en herramientas, documentación y experiencia ajena. El problema aparece cuando dejamos de ver la frontera entre lo que podemos explicar y lo que solo podemos repetir.

Una prueba sencilla consiste en apartar el documento y mantener la conversación. ¿Seríamos capaces de explicar por qué se eligió cada componente? ¿Sabríamos identificar la información que falta? ¿Podríamos adaptar la solución sin volver a pedir al modelo que piense por nosotros? Si la respuesta es negativa, todavía tenemos un borrador útil. Aún no tenemos una decisión.

Lo que un buen dibujo de arquitectura no explica

La arquitectura de software ofrece un ejemplo especialmente claro. Si pedimos a un modelo que diseñe una plataforma de microservicios, probablemente obtendremos un esquema razonable. El dibujo puede mostrar por dónde entran las peticiones, cómo se reparten las funciones, cómo se comunican las piezas, cómo se vigila el sistema y cómo se despliega. Puede ser impecable.

Pero el dibujo solo muestra una parte de la arquitectura.

La arquitectura está en justificar qué se separa y por qué, qué dependencias se aceptan y qué datos corresponden a cada parte del sistema. También exige decidir quién operará cada servicio, qué tiempos de respuesta resultan tolerables, qué deuda técnica se asume para llegar a una fecha y qué señales obligarán a revisar la decisión. A veces obliga a renunciar a una solución elegante porque la organización no tiene capacidad para mantenerla.

Una IA puede proponer alternativas y explicar sus ventajas. El equipo responsable tiene que evaluarlas a la luz de la empresa que operará el sistema. Un patrón correcto en abstracto puede ser una decisión pésima para un equipo pequeño, un presupuesto limitado o una plataforma que no puede interrumpir el servicio. Ahí no basta con información técnica: hace falta criterio aplicado a esa empresa y a sus límites reales.

En tecnología educativa llevo años comprobando algo parecido. Organizaciones que utilizan el mismo sistema de gestión del aprendizaje, o LMS, muestran diferencias importantes en adopción, incidencias y sostenibilidad. No atribuiría esos resultados a una sola causa: intervienen el diseño pedagógico, la accesibilidad, la arquitectura, las integraciones, la gobernanza, la formación, el soporte y el contexto de uso. Para hablar de aprendizaje, además, hacen falta evidencias que lo midan.

Con la IA ocurre lo mismo. Dos personas pueden utilizar el mismo modelo y obtener resultados radicalmente distintos. Una acepta la primera propuesta. La otra aporta documentación, define restricciones, pide alternativas, comprueba las afirmaciones y relaciona la respuesta con decisiones previas. Comparten herramienta; no comparten criterio.

También sucede en producto. Un modelo puede redactar una hoja de ruta convincente sin conocer las tensiones entre usuarios, negocio, tecnología y operación. Puede priorizar funcionalidades con una lógica impecable sobre datos insuficientes. El resultado parece una decisión de producto, aunque todavía sea una hipótesis presentada con seguridad.

Hace veinte años la experiencia servía para producir mejores documentos. Hoy también sirve para saber cuándo un documento aparentemente perfecto está equivocado.

Por qué el prompt perfecto no existe

Cuando una respuesta generada por IA no convence, cada vez aparece antes la misma explicación: «El problema es que no sabes dar buenas instrucciones a la IA, es decir, escribir buenos prompts».

La afirmación contiene una parte de verdad. Una petición clara produce mejores resultados que una instrucción ambigua. Explicar el objetivo, aportar ejemplos y declarar las restricciones ayuda. Formular bien una pregunta sigue siendo una habilidad profesional valiosa.

Lo que no comparto es convertir la redacción de esas instrucciones, el llamado prompt engineering, en sustituto del conocimiento. Un prompt elaborado puede producir una respuesta equivocada. Una pregunta de dos líneas puede encauzar una buena solución cuando detrás hay alguien capaz de aportar el contexto que falta, detectar el error e iterar con criterio.

Un estudio con consultores mostró que existe un límite cambiante entre las tareas que un modelo resuelve bien y otras, aparentemente similares, en las que falla. Dentro de ese límite, las personas que utilizaron IA trabajaron más deprisa y entregaron resultados de mayor calidad. En una tarea compleja situada fuera de él, tuvieron menos probabilidades de llegar a la solución correcta. Parte de los participantes había recibido, además, formación básica para escribir mejores instrucciones. Formularlas bien ayuda, pero no evita tener que reconocer cuándo la tarea supera lo que la herramienta resuelve bien.

El mejor prompt no convierte a nadie en experto. Ayuda a que un experto llegue antes a una buena respuesta, o a que un principiante llegue antes a una respuesta que todavía no sabe evaluar.

Incluso cuando un modelo sigue bien instrucciones formuladas en lenguaje natural, el resultado depende de la tarea, del contexto aportado y de cómo se evalúe. Por eso una parte importante del trabajo se desplaza hacia el diseño de ese contexto: documentación, restricciones técnicas, objetivos, datos fiables, decisiones anteriores y conocimiento del negocio. A esta práctica se la denomina a veces context engineering. El término puede cambiar; el principio es bastante estable.

Aportar contexto no significa volcar documentación interna en cualquier herramienta. La organización debe autorizar los modelos y establecer controles sobre acceso, confidencialidad, datos personales, retención y finalidad. En tecnología educativa, esta precaución alcanza también a la información de alumnos y profesores.

El prompt es una interfaz. Una persona con criterio decide qué información entra, qué respuesta resulta útil y cuándo hay que detenerse para investigar antes de seguir. Confundir ambas cosas equivale a pensar que dominar la sintaxis de una herramienta nos convierte en especialistas del problema que intentamos resolver.

Cuando la velocidad deja de ser progreso

Hace unos años, dedicar dos semanas a una arquitectura podía parecer lento. Hoy podemos obtener un primer borrador en veinte minutos. Es una mejora real, siempre que llamemos borrador a lo que es un borrador.

La dificultad empieza cuando medimos el progreso por la velocidad de producción. La IA permite generar más código, documentación, funcionalidades e informes. Ninguna de esas cifras demuestra por sí sola que el equipo esté tomando mejores decisiones.

La productividad que aporta la IA depende mucho de la tarea y del contexto. En las pruebas con consultores se observaron mejoras en las tareas que el modelo resolvía bien y peores resultados en otra situada fuera de ese ámbito. El límite, además, no es intuitivo: dos tareas que parecen igual de difíciles para una persona pueden recibir respuestas muy distintas. Esa irregularidad obliga a comprobar, no a confiar por costumbre.

Producir más también genera más trabajo de revisión. Cada fragmento de código que vaya a incorporarse a un producto debe integrarse, probarse y quedar bajo mantenimiento. Cada especificación exige validación con quienes conocen el proceso. Cada recomendación necesita contraste con datos y restricciones. El tiempo que se ahorra al redactar a veces reaparece en forma de auditoría, correcciones o deuda técnica.

El problema se agrava si solo medimos la salida. Un equipo puede duplicar el número de funcionalidades y aumentar a la vez las incidencias, el coste de mantenimiento y la complejidad que arrastrará durante años. Desde fuera parecerá más productivo. Desde dentro habrá acelerado en la dirección equivocada.

Terminar antes un documento no significa haber entendido antes el problema. La velocidad aporta valor cuando acorta las tareas mecánicas y libera tiempo para decidir. Si el tiempo liberado se utiliza únicamente para producir el siguiente documento, no hemos ganado espacio para pensar. Solo hemos aumentado el ritmo.

El criterio también se construye durante el proceso

Durante años pensamos que el valor estaba en el resultado final. Cada vez estoy más convencido de que una parte importante del aprendizaje ocurría antes, mientras preparábamos ese resultado.

Escribir una arquitectura obligaba a investigar. Había que comparar alternativas, hablar con otros equipos, descubrir dependencias y volver atrás cuando una hipótesis no resistía. Redactar una propuesta exigía ordenar el problema hasta comprenderlo. Las revisiones podían ser frustrantes, pero también mostraban los huecos del razonamiento.

El documento era visible. El entrenamiento profesional que había detrás no lo era.

Muchas veces no aprendíamos porque terminábamos el documento. Aprendíamos porque escribirlo nos obligaba a pensar.

La IA reduce una parte de esa fricción. Eso puede ser magnífico. No hay ninguna virtud especial en perder horas con una plantilla, buscar una formulación o repetir una tarea mecánica. El riesgo consiste en eliminar también la fricción que nos obligaba a comprender.

Quien empieza necesita oportunidades para analizar, sintetizar, equivocarse y recibir una corrección. Si delega de forma sistemática esas etapas sin sustituirlas por práctica deliberada, corre el riesgo de entrenar menos la capacidad de producir y evaluar resultados por su cuenta. Más adelante, cuando tenga que supervisar una respuesta compleja, quizá le falte precisamente la experiencia que se adquiere resolviendo problemas menos brillantes.

No propongo volver a trabajar como hace diez años. Propongo diseñar el uso de la IA para conservar el aprendizaje. En algunos momentos conviene pedir una propuesta completa. En otros, es mejor formular primero una hipótesis propia, comparar después con la respuesta del modelo y obligarse a explicar las diferencias. También puede pedirse a la IA que critique una decisión, busque contraejemplos o señale qué datos faltan, en vez de encargarle siempre el resultado final.

Conviene reservar el esfuerzo para la parte que construye criterio.

Auditar antes de delegar

Con el tiempo he adoptado una regla sencilla: no convierto una propuesta de IA en una decisión de impacto hasta que una persona o un equipo con competencia suficiente haya podido evaluarla críticamente.

La regla no se aplica del mismo modo a todas las tareas. Corregir una errata, proponer variantes de un título o resumir unas notas tiene un riesgo limitado y es fácil de comprobar. Diseñar una arquitectura, interpretar una obligación legal, recomendar un tratamiento o decidir una inversión exige otro nivel de supervisión. Cuanto mayor sea el impacto, mayor debe ser la capacidad de auditar la respuesta.

Auditar no significa leer por encima y comprobar que el texto suena bien. Significa entender los supuestos, revisar las fuentes, probar los casos límite, contrastar alternativas y explicar por qué la decisión encaja en ese contexto. También significa saber cuándo falta información y detener el proceso.

Defender una decisión no equivale a convencer a los demás. La auditabilidad se demuestra con responsables identificados, evidencia contrastada, criterios de aceptación, pruebas o casos límite y límites documentados. Cuando el riesgo lo exige, también requiere una revisión independiente. Así se evita que la supervisión humana se reduzca a una firma de trámite o a la seguridad retórica de quien presenta la propuesta.

Una organización debería decidir quién puede utilizar un modelo para cada tipo de tarea, qué información necesita, quién valida el resultado y qué evidencias se conservan. Para algunos usos bastará una revisión ligera. Para otros harán falta pruebas, trazabilidad, aprobación formal o la intervención de especialistas. La respuesta correcta depende del riesgo, no de lo impresionante que resulte el modelo.

No delegues en una inteligencia artificial ninguna decisión de impacto cuyo resultado no puedas auditar y defender.

En una organización, auditar y defender una decisión no significa que una sola persona domine cada detalle. Significa que el equipo responsable ha reunido la competencia necesaria, ha contrastado la propuesta y puede explicar el proceso que llevó a aprobarla.

Esto no impide utilizar la IA para aprender ni reserva la herramienta a quienes ya lo saben todo. Podemos recurrir a ella para adentrarnos en un campo nuevo, siempre que tratemos sus respuestas como material de estudio y no como autoridad. El límite aparece cuando una recomendación se convierte en decisión y afecta a otras personas, a un cliente o a una organización.

Cómo creo que deberíamos trabajar con la IA

Creo que no basta con pedir un resultado a una inteligencia artificial y revisarlo al final. Esa revisión suele llegar demasiado tarde: el equipo ya ha aceptado el planteamiento, el lenguaje y buena parte de los supuestos de la primera propuesta. Propongo diseñar el proceso completo para que una sugerencia del modelo, una decisión profesional y una acción sobre un sistema sigan siendo tres cosas distintas.

Primero, definir la decisión antes de elegir la herramienta. Hay que explicar qué problema se intenta resolver, para quién, con qué beneficio y qué ocurriría si el resultado fuese incorrecto. También conviene dejar por escrito qué usos quedan fuera, qué daño sería inaceptable y cuál es la alternativa si la IA no alcanza el nivel exigido. Si un equipo no puede describir el problema sin hablar del modelo, todavía no está preparado para decidir cómo incorporarlo.

Segundo, ajustar el control a las consecuencias. No necesita el mismo proceso una ayuda para resumir notas que una recomendación que afecte a la seguridad, a un presupuesto, a la continuidad de un servicio o al aprendizaje de una persona. Yo clasificaría cada uso por el impacto de un error, la cantidad de personas afectadas y la dificultad de revertir la decisión. De esa clasificación deben salir el nivel de prueba, la revisión necesaria, quién puede aprobar el resultado y cuándo es obligatorio detenerse.

Tercero, asignar responsables con autoridad real. Todo uso relevante debe tener una persona que responda por el objetivo, otra persona o equipo competente para validar el resultado cuando sea necesario y alguien preparado para operar la solución. Pueden coincidir o no, pero los papeles deben estar claros. Incluir a una persona en el circuito no sirve de mucho si no tiene conocimiento suficiente, tiempo para revisar o autoridad para rechazar la propuesta. La supervisión humana solo aporta garantías cuando puede cambiar la decisión.

Cuarto, controlar el contexto, los datos y las dependencias. Un sistema no debería recibir toda la información disponible, sino únicamente la necesaria y autorizada para la tarea. Antes de utilizar datos personales, información confidencial o documentación interna, hay que decidir quién puede acceder, con qué finalidad, durante cuánto tiempo se conserva y qué tercero puede procesarla. También debemos saber qué modelos, versiones, fuentes, repositorios, integraciones y herramientas forman parte de la solución. Un prompt no es una caja fuerte y una respuesta bien redactada sigue siendo un dato que el resto del sistema no puede dar por fiable.

Quinto, limitar la autonomía y los permisos. Mi criterio es empezar permitiendo que la IA lea y recomiende, y ampliar después solo lo que haya demostrado ser necesario. Una IA no debería poder modificar datos, enviar comunicaciones, desplegar código, aprobar pagos o cambiar permisos porque resulte cómodo conectarla a esas funciones. Debe disponer del mínimo conjunto de herramientas, permisos y autonomía compatible con su objetivo. Las acciones de impacto necesitan validaciones deterministas y, cuando la consecuencia lo justifique, una aprobación humana explícita. También hacen falta límites de consumo, tiempo y coste: un sistema que puede seguir actuando sin tope no solo introduce riesgo técnico, sino también riesgo económico.

Sexto, intentar romper la solución antes de aprobarla. No basta con comprobar que funciona en casos favorables. Hay que probar casos representativos y situaciones límite, instrucciones ambiguas, información incompleta, datos contradictorios y entradas manipuladas. Debemos observar cuándo inventa, cuándo revela algo que no debería, cuándo utiliza una herramienta equivocada y cómo se comporta si una fuente externa contiene instrucciones maliciosas. Los criterios de aceptación tienen que definirse antes de ver los resultados para no rebajar la exigencia a medida que aparecen fallos. Y en decisiones de alto impacto conviene que la revisión no dependa únicamente del equipo que construyó la solución.

Séptimo, medir el comportamiento en producción. Aprobar una versión no cierra el trabajo. Hay que saber qué modelo y qué configuración produjeron cada resultado relevante, qué fuentes se consultaron, qué herramientas se invocaron y quién autorizó una acción, sin convertir esa trazabilidad en una acumulación indiscriminada de datos sensibles. Yo vigilaría, como mínimo, la calidad de las respuestas, los errores, los rechazos humanos, las incidencias, el coste, la latencia y los cambios de comportamiento. Si cambia el modelo, la información de entrada, el volumen de uso o una integración, parte de la evaluación debe repetirse.

Octavo, preparar la respuesta ante fallos antes del despliegue. Toda solución necesita una forma segura de detenerse, volver a un estado anterior y continuar el servicio sin depender del componente de IA. El equipo debe saber qué señales obligan a suspenderla, quién toma esa decisión, cómo se revierte una acción y cómo se informa a las personas afectadas. La pregunta no es solo si el sistema puede funcionar bien, sino si la organización sabrá reaccionar cuando funcione mal.

Noveno, revisar y aprender de forma continua. Los riesgos no permanecen quietos. Cambian el contexto, los usuarios, los datos, los proveedores y las capacidades de los modelos. Por eso no trataría la puesta en producción como una aprobación indefinida. Revisaría periódicamente si el uso sigue teniendo sentido, si los controles continúan funcionando y si el beneficio obtenido compensa el coste y el riesgo asumidos. Las incidencias, las decisiones revertidas y las correcciones de los especialistas deberían servir para ajustar la siguiente versión del proceso.

Este enfoque puede parecer más lento que conectar un modelo y empezar a generar resultados. En realidad, evita que la velocidad inicial se pague después en forma de incidentes, sobrecostes, rediseños o decisiones que nadie sabe defender. Para mí, la gobernanza sirve si permite saber qué estamos haciendo, medir cómo se comporta la solución, limitar lo que puede ocurrir y corregir el rumbo a tiempo.

Mi forma de trabajar sigue este orden: primero entiendo la decisión, después delimito el riesgo, luego pruebo la solución y solo entonces permito que actúe.

La responsabilidad sigue teniendo nombre y apellidos

Abrir la imagen a tamaño completo

Delegar la redacción no equivale a delegar la responsabilidad. Una arquitectura puede haberla propuesto un modelo. El código puede proceder de un asistente. Un informe puede haberse preparado con varias herramientas. Cuando ese sistema llegue a producción, alguien seguirá respondiendo por la decisión.

El cliente no discutirá con el modelo. Preguntará al equipo por qué se eligió esa solución. Si aparece una incidencia, «lo recomendó la IA» no constituirá por sí solo un análisis de causa suficiente. Y cuando una decisión afecte a la seguridad, al aprendizaje de un alumno, a un presupuesto o a la continuidad de un servicio, la responsabilidad deberá estar asignada a la organización y a funciones identificables. No puede trasladarse al modelo.

Esta realidad cambia el papel de los perfiles con experiencia. Una parte de su trabajo dejará de consistir en producir el primer borrador. Tendrán que definir criterios de aceptación, diseñar revisiones, formar a quienes utilizan las herramientas y establecer qué decisiones requieren supervisión especializada. Es menos vistoso que generar una demo en cinco minutos, pero permite operar con garantías.

También obliga a revisar cómo medimos el rendimiento. Si premiamos únicamente la velocidad o el volumen, empujaremos a los equipos a aceptar resultados sin comprobar. Si medimos calidad, mantenibilidad, incidencias, decisiones revertidas y aprendizaje, el uso de la IA se orientará hacia el valor que puede aportar.

La responsabilidad no exige desconfiar de todo. Exige conservar la capacidad profesional de decidir y responder por lo decidido. Una persona puede apoyarse mucho en la IA y seguir siendo responsable si entiende el problema, cuestiona la respuesta, decide con evidencia y documenta los límites. La herramienta amplía su capacidad. No firma en su lugar.

Utilizar más IA para pensar mejor

Deberíamos utilizar la inteligencia artificial de forma más deliberada: para ampliar nuestra capacidad de explorar y comprobar, sin reducir el pensamiento que dedicamos a una decisión.

La utilizo para obtener alternativas que no había considerado, localizar contradicciones en un borrador, resumir documentación extensa y preparar preguntas antes de una reunión. También resulta útil para ensayar objeciones: puedo pedirle que actúe como un arquitecto preocupado por la operación, como un responsable financiero que cuestiona el coste o como un usuario que no entiende el proceso. Ninguna de esas respuestas decide por mí. Mejoran la conversación que tendré después.

En el trabajo profesional, un buen uso de la IA mantiene a una persona al mando en cuatro pasos. Primero se define qué decisión hay que tomar. Después se aporta el contexto necesario. A continuación se somete la respuesta a contraste, con pruebas, fuentes o especialistas. Por último, una persona asume la decisión y deja constancia de sus límites.

La IA puede intervenir en todos esos pasos. Puede ayudar a formular el problema, detectar información que falta, preparar pruebas y explicar una decisión. Lo que no conviene es permitir que la fluidez del modelo borre la transición entre propuesta y aprobación.

Cuando alguien me pregunta cómo utilizar la IA en su trabajo, cada vez respondo de forma más sencilla: úsala para cuestionar más tus ideas. Pídele alternativas y que busque el fallo; después, discute sus supuestos. Si llega un momento en que dejas de discutir con ella y empiezas a obedecerla, habrá dejado de ser una herramienta para convertirse en un sustituto de tu criterio.

Utiliza la IA para acelerar tu capacidad de pensar. Nunca para sustituirla.

La diferencia entre tener criterio y tener respuestas

Durante años nos preguntamos si la IA sustituiría a los expertos. Puede que esa pregunta nos haya distraído de otra más cercana: qué ocurre con nuestra experiencia cuando siempre tenemos una respuesta disponible.

La IA puede elevar el nivel medio de muchos documentos y permitir que más personas hagan trabajos que antes estaban fuera de su alcance. Es una mejora real. A la vez, puede hacer más visible la diferencia entre quien entiende una decisión y quien solo puede reproducirla, pero no justificarla cuando cambian las condiciones.

Los profesionales con criterio no serán valiosos porque escriban más deprisa que un modelo. Lo serán porque reconocen una restricción que no aparece en el prompt, recuerdan una consecuencia que el equipo ya sufrió, conectan la recomendación con el negocio y saben decir «todavía no tenemos información suficiente».

Esa capacidad no es infalible. La experiencia también se equivoca, se aferra a soluciones conocidas y puede rechazar una idea nueva demasiado pronto. La IA sirve precisamente para combatir parte de esos sesgos si la utilizamos como interlocutor y no como oráculo. El criterio profesional incluye discutir con la herramienta y estar dispuesto a cambiar de opinión cuando aparecen mejores evidencias.

No sé si dentro de unos años seguiremos hablando de prompt engineering, context engineering o de términos que todavía no existen. Sí sé que seguiremos necesitando personas capaces de asumir decisiones complejas cuando no haya una respuesta evidente. Personas que puedan explicar por qué una solución aparentemente correcta no encaja, pedir más información antes de avanzar y responder por lo que finalmente se entrega.

Mi hipótesis es que la inteligencia artificial no está elevando el nivel de todos los profesionales por igual. Puede ampliar la diferencia entre quienes someten sus respuestas a criterio y quienes se limitan a reproducirlas.

La pregunta con la que me quedo es incómoda, pero útil: ¿estás utilizando la IA para pensar mejor o para pensar menos?