La IA no sustituye el criterio experto: lo hace más necesario
Cuando producir respuestas deja de ser lo difícil, el valor se desplaza hacia la capacidad de cuestionarlas, contextualizarlas y asumir sus consecuencias.
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 sustituye el criterio experto: lo hace más
necesario.
El mecanismo es 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 22 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 encargo había situado todo el análisis técnico en perfiles que no debían realizarlo solos.
Al leerlo, empecé a plantear preguntas. Quise saber cómo se había resuelto la observabilidad de la solución, cómo responderí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. El documento describía una funcionalidad sin analizar 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 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.
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 proliferación de documentos con apariencia experta. 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ó una mejora media de productividad del 14 %, 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. El problema se revela 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.
La IA no produce el mismo efecto en todas las personas ni en cualquier tarea. 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 una falsa 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.
Todos trabajamos apoyados en herramientas, documentación y experiencia ajena. El riesgo 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 consiste 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, aparece cada vez con más frecuencia 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 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.
Escribir el documento nos obligaba a pensar y ahí ocurría buena parte del
aprendizaje.
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. Corregir una errata o resumir unas notas admite una comprobación ligera; diseñar una arquitectura, interpretar una obligación legal o decidir una inversión exige más evidencia y supervisión.
Auditar significa entender los supuestos, revisar las fuentes, probar casos límite, contrastar alternativas y saber cuándo falta información. La decisión debe conservar responsables identificados, criterios de aceptación, evidencia y límites documentados; cuando el riesgo lo exige, también una revisión independiente.
No delegues en una inteligencia artificial ninguna decisión de impacto cuyo
resultado no puedas auditar y defender.
| Impacto del error | Control mínimo |
|---|---|
| Bajo | Revisión ligera y comprobación básica |
| Relevante | Pruebas definidas, responsable y aprobación |
| Alto | Trazabilidad, revisión independiente, reversión y seguimiento |
Auditar no exige que una sola persona domine cada detalle, sino que el equipo reúna la competencia necesaria y pueda explicar por qué aprobó la propuesta. La IA también puede servir para aprender si sus respuestas se tratan como material de estudio; el control adicional aparece cuando una recomendación se convierte en una decisión que afecta a otras personas o a la organización.
Cómo creo que deberíamos trabajar con la IA
Pedir un resultado a una inteligencia artificial y revisarlo solo al final suele ser insuficiente. Esa revisión llega 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. El recorrido favorable solo es el comienzo. 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. Además de comprobar si el sistema puede funcionar bien, hay que demostrar que 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
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. Además de producir, deben definir criterios de aceptación, diseñar revisiones, formar a quienes usan las herramientas y señalar qué decisiones requieren supervisión especializada. Si la organización mide calidad, mantenibilidad, incidencias y aprendizaje, en lugar de premiar solo velocidad y volumen, la IA puede ampliar esa capacidad profesional sin firmar en lugar de quien responde por la decisión.
Utilizar más IA para pensar mejor
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: ayuda a formular el problema, detectar información que falta, preparar pruebas y explicar una decisión. Su fluidez no debe borrar la transición entre propuesta y aprobación; resulta más útil pedirle alternativas, fallos y objeciones que obedecer la primera respuesta.
Utiliza la IA para ampliar tu capacidad de pensar, nunca para sustituirla.
La diferencia entre tener criterio y tener respuestas
Los profesionales con criterio serán valiosos 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 cuando actúa como interlocutor crítico. 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?
Más de 22 años construyendo y evolucionando plataformas de aprendizaje en producción.
Sobre Alberto Lara y su trayectoria profesional →Seguir leyendo
- Qué hacía antes un desarrollador y qué tiene que hacer ahora con agentes de IA
Qué cambia en el trabajo del desarrollador cuando delega parte de la implementación en agentes de IA: análisis, contexto, programación, pruebas y responsabilidad.
- Tu proveedor de servicios gestionados va a ser un agente (y es una buena noticia)
Cómo evolucionan las altas, las matriculaciones y el resto de la administración de Moodle desde el CSV hasta agentes con permisos, confirmación y trazabilidad.
- Cómo saber si la IA está aumentando realmente la productividad
La velocidad es una de las mejoras más visibles que introduce la inteligencia artificial y, precisamente por eso, también puede convertirse en una de las más engañosas.