Etiqueta: Gobernanza IA

Riesgo, continuidad de negocio, dependencia de proveedor

Publicado el

La IA y la vuelta a la época de Lotus 1-2-3 y dBASE III

Oficina corporativa de los años noventa con monitores CRT, archivadores metálicos y empleados con ropa de la época, junto a un androide moderno integrado como un compañero más.

Hay una época de la informática que recuerdo con cierta mezcla de nostalgia y prevención —no la viví profesionalmente, pero sí a través de mi padre y mis tíos—: cuando un departamento gestionaba sus cosas en dBASE III, otro lo hacía con Lotus 1-2-3, y el departamento de informática se dedicaba a su AS-400.

Esto me ha venido a la cabeza estos días. Esta semana me construí un script de transcripción local. No porque las alternativas del mercado sean malas, sino porque ninguna encajaba exactamente en mi flujo de trabajo.

Necesitaba algo que procesase el audio en local, a coste cero, con el ordenador que tengo. Lo mismo me está pasando con mi sistema de gestión de la bóveda de conocimiento. He probado Graphify, pero me tenía que adaptar a su forma de funcionar así que estoy montándome mi propia solución.

Hace unos meses escribí en Hábitos viejos con herramientas nuevas sobre cómo la reutilización fue durante décadas la respuesta racional a la escasez de recursos: construir algo a medida era caro, así que hacerlo genérico tenía sentido. Ese razonamiento ya no aplica de la misma manera.

No soy el único

Javier Garzás, consultor de transformación digital con más de 20 años en el sector, está hablando de que su equipo está haciendo desarrollos a medida con IA. Hay más gente en la misma dirección: personas que están cancelando suscripciones que antes pagaban sin cuestionarlas y construyendo sus propias alternativas adaptadas a su caso concreto.

En mi caso, que trabajo solo desde casa, esto no tiene ningún riesgo organizativo. Si mi script de transcripción solo me sirve a mí, ese es exactamente el objetivo. Puedo construir herramientas sin ninguna vocación de escala.

El problema llega cuando esto empieza a ocurrir dentro de una empresa.

La historia que ya vivimos (y estamos a punto de repetir)

Nadie planeó usar Lotus 1-2-3 y dBASE III así. Ocurrió porque construirse algo propio era lo más rápido y funcional en ese momento. El problema llegaba cuando parte de la gestión de la empresa estaba en la sombra: sin copias de seguridad, sin controles, sin que nadie del departamento de informática supiera que existía. Hoy lo llamaríamos Shadow IT.

Con la IA, estamos volviendo ahí. Pero a otra escala.

Antes, hacer tus propias soluciones requería cierto conocimiento técnico: instalar una aplicación SaaS no autorizada, registrarse en un servicio externo que IT no había aprobado. Ahora, cualquier empleado puede pedirle a Claude que le construya un script, una automatización o una integración que no pasa por ningún proceso de validación técnica. Cada uno con su solución. Nadie con visión de conjunto.

La gobernanza que viene

La respuesta obvia es prohibirlo. Pero ya sabemos cómo terminó esa historia con el BYOD, con el cloud o con WhatsApp en entornos corporativos: la gente sigue usando lo que le resulta más cómodo y productivo, solo que fuera del radar.

Lo que sí puede funcionar es una gobernanza que entienda la nueva realidad: construir software a medida ya no es una excepción técnica, sino una práctica habitual que se va a extender. El objetivo no es impedirlo, sino encauzarlo.

En la práctica, eso implica tres cosas: principios claros sobre dónde puede desplegarse código generado con IA; criterios para distinguir un script personal de una solución corporativa encubierta; y capacidad para detectar cuándo algo que empezó como una automatización individual se ha convertido en infraestructura crítica que solo entiende quien la construyó. Eso no es una prohibición. Es criterio aplicado a escala.

La gobernanza de la IA va a ser muy importante. Pero tendrá que ser flexible, porque imponer soluciones rígidas no tiene sentido cuando lo que se está viendo es que es muy barato y muy rápido construirte algo a medida.

Moraleja

La IA ha democratizado el traje a medida. Eso es una buena noticia para las personas con criterio suficiente para aprovecharlo. Para las organizaciones, es una nueva fuente de riesgo que todavía no está en la mayoría de los planes de gobernanza. La pregunta no es si tus empleados están construyendo soluciones propias con IA. Es si sabes cuáles son, dónde están y qué pasaría si mañana dejasen de funcionar.

Es la pregunta que pocas organizaciones se están haciendo todavía. ¿La tuya sí? Cuéntame en LinkedIn.

Relacionados sugeridos

Publicado el

Soberanía de IA: la mía cabe en un Mac Mini

Androide humanoide trabajando con un portátil en una mesa de madera, con una txapela vasca negra apoyada sobre la mesa.

He estado en el Open LLM Basque Day. Ponencias, debates, café con unas vistas excepcionales desde la planta 29 de la Torre Iberdrola. Y una palabra que aparecía en cada conversación: soberanía.

Soberanía tecnológica. Soberanía del dato. Modelos que no dependan de Washington ni de Pekín. En el mismo Bilbao, Elhuyar lleva décadas en tecnologías del lenguaje y ya tiene Llama-Eus. En HITZ, el centro de la EHU, adaptan modelos de Meta para euskera. En España, Alia es la infraestructura pública de IA del Gobierno: modelos abiertos en castellano y lenguas cooficiales —incluido el euskera—, entrenados en MareNostrum 5. En Suiza entrenan Apertus con 11.000 GPUs. El ecosistema está más cerca de lo que parece, y el debate es completamente legítimo.

Pero cuando volvía a casa, pensaba en mi versión de la soberanía. Que tiene bastantes menos GPUs.

De ChatGPT a Claude: lo que no he contado

Hace un año escribí sobre por qué volví a escribir en el blog y cómo un GPT personalizado con el corpus de mis posts me lo había puesto fácil. Lo que no he contado es todo lo que pasó después.

ChatGPT funciona bien para muchas cosas, pero hay un límite que me fue resultando incómodo: todo lo que le das vive en sus servidores. Tu corpus de textos, tus documentos, tus conversaciones. Eso no es soberanía. Es comodidad. Y no son lo mismo.

El salto a Claude no fue repentino. Fue gradual, y vino acompañado de un replanteamiento más profundo de cómo gestiono el conocimiento.

El experimento que no funcionó (y lo que aprendí de él)

En mayo escribí sobre el ruido que genera la IA cuando la usas sin criterio. Sin nombrarlo, hablaba de un sistema que se había puesto de moda: la idea de que un LLM puede actuar como mantenedor de una wiki personal, capturando todo lo que lees, generando resúmenes y cruzando referencias de forma automática.

La idea venía de Andrej Karpathy. Técnicamente sólida. Conceptualmente atractiva.

El problema fue la práctica: el sistema generaba tanto output —resúmenes, síntesis, notas automáticas— que acabé gestionando la IA en lugar de gestionar el conocimiento. Más ruido, no más señal. Lo quité.

Del experimento, sin embargo, me quedé con algo que sí tenía sentido: la búsqueda local.

La bóveda: manual, pero mía

Lo que monté en su lugar es más modesto y más deliberado.

Una bóveda en Obsidian donde archivo lo que leo —artículos, ponencias, transcripciones— con resúmenes generados por agentes de Claude. No es automatización ciega: cada activo pasa por un proceso que yo controlo. El LLM hace el trabajo tedioso de resumir y cruzar referencias; yo dirijo qué entra, qué se descarta y cómo se organiza.

La pieza clave que conservé del concepto original es QMD: un motor de búsqueda que funciona localmente, sin nube, sin API externa. Combina búsqueda por palabras clave y búsqueda semántica, y el índice vive en mi máquina. Cuando Claude Code necesita contexto para redactar un post o detectar conexiones entre ideas, consulta QMD. Sin enviar nada a ningún servidor externo, ni consumir tokens.

Eso es mi soberanía. No un modelo propio. No 11.000 GPUs. Un índice local en un Mac Mini.

Lo que ha cambiado en el flujo editorial

El resultado práctico es que el blog ya no funciona como antes.

Antes: una idea → un audio → ChatGPT → un post. Rápido, pero sin memoria. Cada artículo salía de la nada.

Ahora: una idea conecta con lo que he leído, con las ponencias que he procesado, con los autores que he archivado. Este mismo artículo sobre soberanía tiene contexto de la ponencia que escuché esta semana, cruzado con un documento que procesé hace mes y medio sobre gestión de conocimiento con LLMs. Sin buscar manualmente nada. La diferencia no es de velocidad, es de profundidad.

El sistema tiene memoria. Y esa memoria es local.

Sé que a escala de empresa esto suena a bricolaje. Y técnicamente lo es. A veces la mejor forma de entender un patrón es montarlo tú mismo a escala mínima. Pero el patrón es el mismo que se discutía en el Open LLM: quién controla los datos, quién puede consultarlos, quién decide qué se archiva.

Moraleja

La soberanía de IA no es solo un problema de estados y grandes organizaciones. Existe también a escala personal, y las implicaciones son parecidas: ¿dónde vive tu conocimiento? ¿Qué pierdes si cambias de proveedor?

Mi versión es modesta. Pero cuando pasé de ChatGPT a Claude, no perdí nada. Porque nada dependía de la nube.

A veces la soberanía no requiere 11.000 GPUs. Requiere criterio y un par de horas montando algo a mano.

¿Tienes algún sistema propio para gestionar lo que aprendes, o lo delegas todo a herramientas en la nube? Cuéntamelo en LinkedIn

Relacionados sugeridos

Publicado el

El médico ya sabe dónde derivarte. ¿Cuánta IA necesitas realmente?

Doctora frente a un ordenador con una interfaz médica en pantalla, seleccionando manualmente un centro de derivación de un desplegable de autocompletado.

Hace años estaba trabajando en una aplicación de sanidad. Teníamos que diseñar una pantalla para que el médico pudiera solicitar una radiografía, y uno de los campos era el centro al que derivar al paciente.

Como buenos informáticos —con ese impulso natural de automatizar todo lo que se mueve—, propusimos que el sistema rellenara ese campo automáticamente. Teníamos unas tablas con los centros disponibles, los criterios de derivación… parecía sencillo y eficiente.

El responsable funcional nos paró en seco.

«El médico ya sabe a qué centro tiene que ir el paciente», nos dijo. «Si automatizamos demasiado, se nos puede escapar alguna casuística que no controlamos, porque tampoco conocemos todas las posibilidades. Al final acabamos poniendo límites donde no deberían estar. Lo que tenemos que hacer es facilitarle la selección: favoritos, autocompletado. Nada más.»

Tenía razón. Y esa conversación lleva años rondándome la cabeza.

La IA es solo la siguiente capa

Lo que estamos viviendo con la inteligencia artificial es, en esencia, un salto más en el nivel de automatización. Un salto enorme, eso sí, pero con la misma trampa de siempre: la tentación de automatizarlo todo.

Y el riesgo ahora es mayor. Porque la IA no es determinista. No hace lo mismo dos veces de la misma manera. Puede alucinar —ese término tan gráfico del argot técnico, que describe cómo el modelo inventa algo con total convicción—, y eso añade una variable que las tablas de un sistema de sanidad nunca tenían.

Cuanto más se automatiza sin supervisión, más se amplía la superficie donde algo puede salir mal de una forma que no habíamos previsto.

Humano en el bucle, pero al mando

Hay una frase que se usa mucho últimamente: human in the loop. Suena bien. Ya escribí sobre quién es realmente ese humano y qué capacidad tiene de validar, porque a veces el control se convierte en decorado: el humano está ahí, pero sin entender lo que está supervisando.

Lo que yo hago va un paso más atrás: estar en el bucle, y al mando desde el principio.

No como espectador de lo que la IA decide, sino como quien dirige el proceso y delega tareas específicas —las más mecánicas, las más repetitivas— con plena conciencia de lo que está delegando y por qué.

He probado herramientas y flujos de trabajo con IA que prometían mucho, y he quitado los que no me convencían. No porque la tecnología fallara, sino porque no me daban esa sensación de control y al final era yo el que me tenía que adaptar a la herramienta.

El ritmo lo marcan las personas, no la tecnología

Hay un factor que a veces se pasa por alto en esta conversación: el rechazo.

Hay escepticismo hacia la IA, y no es irracional. Es la respuesta natural de quien ve una tecnología que cambia las reglas del juego y no sabe bien si está de su lado o en su contra.

Si automatizamos demasiado pronto —antes de que la gente haya podido interiorizar cómo funciona y qué controla—, lo único que conseguimos es alimentar ese escepticismo. La persona no entiende lo que pasa, no se fía, y acaba rechazando la herramienta.

La adopción real no la marcan las capacidades técnicas. La marcan las personas que tienen que usar esa tecnología cada día.

Cuando alguien entiende que la IA trabaja para él —que la controla, que puede corregirla, que no va a remolque de ella— el rechazo se convierte en curiosidad. Y la curiosidad, con el tiempo, en confianza.

Y entonces sí: se puede ir automatizando más. Gradualmente, con evidencias, con esa confianza ya construida.

Moraleja

El funcional de aquella pantalla de sanidad lo resumió sin saberlo: a veces la mejor automatización es la que no se hace. Lo más inteligente es facilitarle al humano que haga lo que ya sabe hacer, en lugar de intentar sustituirlo.

La IA permite cosas que antes eran impensables. Pero la velocidad a la que se adopta no la decide la tecnología: la decide la persona que tiene que usarla.

El objetivo no es que la IA haga más, sino que el humano haga mejor. Y para eso, el humano tiene que seguir llevando el volante.

¿En tu entorno habéis automatizado más de la cuenta y habéis tenido que dar marcha atrás? Cuéntamelo en LinkedIn

Relacionados sugeridos

Publicado el

¿Qué haces cuando se te va la IA?

Dos androides recogen sus cosas en cajas de cartón mientras sus compañeros humanos los observan desde sus puestos de trabajo en una oficina moderna

He visto cómo en una semana se marchaba la fila entera de una mesa corrida. No uno, no dos: todos. Cuando pasa algo así, la organización lo nota. Hay un vacío, hay que redistribuir carga, hay que reclutar, hay que formar. Es duro, pero las empresas saben cómo gestionarlo. Tienen protocolos. Tienen planes. Llevan décadas aprendiendo a gestionar el riesgo de que una persona se vaya.

Lo que no han aprendido todavía es qué hacer cuando se les va la IA.

La IA como compañero de trabajo

Para entender el problema de la gobernanza de la inteligencia artificial, me resulta útil hacer un símil sencillo: tratarla como si fuese una persona.

Piénsalo así. Cada persona de tu equipo tiene ahora, o tendrá muy pronto, un asistente de IA. No una herramienta genérica que todos comparten, sino algo que les ayuda a ellos específicamente: a redactar, a analizar, a buscar, a resumir, a revisar. Una especie de compañero invisible que, de momento, no pide vacaciones ni se queja del café. Pero que tampoco negocia.

Si ese «compañero» fuese una persona de carne y hueso, ya sabrías qué hacer si un día te dice que se quiere ir. Tienes conversaciones, negocias condiciones, buscas sustituto, cubres temporalmente las tareas. Es un proceso conocido, con fricciones, pero manejable.

El problema es que la IA no funciona así.

El riesgo que nadie ha puesto en el plan de continuidad

Cuando el compañero de IA de todos tus empleados depende del mismo proveedor externo, el riesgo deja de ser individual para convertirse en sistémico.

Si ese proveedor decide subir sus precios un 40%, no te afecta a una persona: te afecta a todas a la vez. Si hay una restricción geopolítica — algo que, como hemos visto con los aranceles y las tensiones tecnológicas entre bloques, ya no es ciencia ficción — no pierdes un perfil: pierdes la capa de asistencia de toda tu organización de golpe. Y lo más importante: no puedes negociar. No hay una conversación que tengas. No hay palanca.

Con una persona, siempre hay margen de maniobra. Con un proveedor de IA al que dependes estructuralmente, muy poco.

En el congreso ApplAI de este año esto se mencionó de forma explícita: la dependencia de modelos en la nube crea un ciclo de vida que la empresa no controla. Cualquier cambio en ese entorno — técnico, comercial o regulatorio — puede afectar seriamente al funcionamiento de sistemas que ya están integrados en el día a día. Y el riesgo geopolítico está ahí: cualquier día de estos, un problema de aranceles en el mundo de la tecnología puede dejarte con un servicio al que no puedes acceder.

La pregunta que pocas empresas se han hecho

Todas las organizaciones tienen un plan de recuperación ante desastres para sus sistemas de IT. Tienen procedimientos para cuando cae el servidor, para cuando falla la base de datos, para cuando hay un incidente de ciberseguridad.

¿Tienen uno para cuando se quedan sin IA?

¿Cuántas personas de la organización dependen hoy de un único proveedor de IA? ¿Qué procesos críticos están apoyados en esa dependencia? ¿Cuánto tiempo tardarían en migrar a otro proveedor, o en operar sin esa capa de asistencia? ¿Se ha evaluado siquiera?

Estas son las preguntas que la gobernanza de la IA debería estar respondiendo. No como un ejercicio teórico, sino con la misma seriedad con la que se planifica la continuidad del negocio ante cualquier otro riesgo operativo.

Gobernanza no es un formulario de cumplimiento

Cuando se habla de gobernanza de la IA en muchas organizaciones, el debate se va rápidamente hacia la ética, la regulación o los comités de supervisión. Todo eso es necesario. Pero hay una dimensión más inmediata que a menudo queda fuera del foco: la gestión de la dependencia tecnológica.

Los directivos que han implantado IA en sus organizaciones con más criterio no la tratan como una herramienta más que se conecta y ya. La gobernanza para ellos significa tener claro el marco de control de riesgos desde el principio: qué decisiones se automatizan y cuáles requieren supervisión humana, qué datos salen de la organización y cuáles no, qué ocurre si el proveedor cambia las condiciones.

Eso no es burocracia. Es anticiparse.

Lo que aprendí viendo marcharse a una fila entera

Cuando una fila de compañeros se va en una semana, el impacto se nota. Pero la organización sobrevive porque el conocimiento, aunque distribuido y aunque costoso de recuperar, no desaparece del todo. Queda algo: los procesos documentados, la memoria institucional, los compañeros que se quedan.

Con la IA, si la dependencia está mal construida, no queda nada. O peor: queda un vacío donde antes había velocidad, y una organización que no sabe cómo operar sin ella porque nunca se lo planteó.

La buena noticia es que no es difícil de formular: ¿qué hacemos si mañana nos quedamos sin IA?

Las organizaciones que hayan pensado en esa respuesta antes de necesitarla son las que van a navegar los próximos años con más solidez. No las que adoptaron más rápido, sino las que adoptaron con criterio.

Eso es gobernanza. El resto es decoración.

Relacionados sugeridos

¿Tu organización tiene un plan de continuidad para la IA? Cuéntamelo en LinkedIn.

Publicado el

¿Quién supervisa a la IA cuando sabe más que tú?

Una supervisora observa a varios androides trabajando con ordenadores en una oficina, con expresión de duda sobre cómo validar lo que hacen.

Hace unos días me encontré en una situación curiosa: le pido algo a un agente de Codex y, para resolverlo, se pone a generarse “sus herramientas” en Python.

El resultado que me entrega funciona, pero hay una parte que me deja incómodo: yo no conozco Python. Y si no conozco Python, mi capacidad de validar si ese script está bien hecho o si está a punto de romperse es, siendo honestos, limitada.

Y ahí me saltó una alarma que va mucho más allá del lenguaje.

El «humano en el bucle»… ¿qué humano?

En teoría, la adopción de IA en desarrollo se apoya en una idea tranquilizadora: siempre hay un humano supervisando.

Eso funciona cuando el humano entiende el terreno. Si la IA me ayuda en un proyecto Java y yo conozco Java, puedo juzgar si lo que propone encaja con lo que el proyecto requiere, si huele raro, o si me estoy comprando un problema para dentro de dos sprints.

Pero cuando la IA decide que la mejor forma de ayudar es construirse piezas en un lenguaje que yo no domino, el «humano en el bucle» empieza a parecerse más a un sello de “aprobado” que a una supervisión real. No porque haya mala fe. Porque el bucle se rompe por asimetría de conocimiento.

Cuando la IA migra cosas que tu equipo no conoce

Pienso en un escenario bastante plausible: migraciones. Por ejemplo, coger aplicaciones heredadas tipo J2EE y moverlas a frameworks más modernos, como Spring.

En el momento en que estas herramientas hagan esas migraciones “bien” de forma automática, el humano que está supervisando puede no ser quien más sabe del destino. Y entonces aparece una tensión incómoda:

  • La IA puede saber más que el humano sobre “ese tema concreto”.
  • Y el humano puede quedar relegado a validar por intuición, por pruebas indirectas o por confianza.

No es un problema abstracto: es un cambio de responsabilidades.

El desajuste que se cuela en los equipos

Esto conecta con otro desajuste que ya he comentado en algún post previo: cuando una parte del equipo gana productividad por la IA más rápido que otra.

Si llega un punto en el que los programadores producen mucho más de lo que un analista es capaz de “alimentar”, tienes un cuello de botella nuevo. Y si, además, la IA está empujando trabajo hacia tecnologías que el equipo no domina, el cuello de botella puede convertirse en algo peor: una revisión superficial de decisiones que nadie está en posición de discutir.

La velocidad es lo que más me preocupa

De todo esto, lo que más me inquieta no es que ocurra, sino la velocidad a la que está ocurriendo.

En mi caso, la forma de gestionar este blog en verano no tiene nada que ver con cómo lo estoy gestionando en Navidades, y no han pasado ni seis meses. Eso, llevado al desarrollo de software, es una señal clara: nuestros hábitos de validación y supervisión tienen que evolucionar al mismo ritmo que la herramienta.

Si no, el «humano en el bucle» se queda como una frase bonita… justo cuando más falta hace.

Moraleja

La promesa no era “una IA que hace cosas”, sino “una IA que hacemos responsablemente”. Y para eso, el humano en el bucle no puede ser decorativo: tiene que ser competente en lo que está validando, o el bucle deja de ser un control y pasa a ser un trámite.

¿En tu equipo quién está validando de verdad lo que hace la IA cuando el trabajo cae fuera de vuestro stack? Te leo en LinkedIn.

Diseñado en la cabeza de Iñigo, made in ChatGPT.

Relacionados sugeridos

Publicado el

¿Quién entrena a tu IA? La nueva guerra del conocimiento

Dos personas encajan piezas de puzzle translúcidas con borde naranja en la cabeza de un robot sobre una mesa de cristal; estanterías azul oscuro al fondo. Metáfora de quién entrena la IA.

Hace unos años, cuando llegaba un nuevo programador al equipo, lo normal era darle un portátil, acceso al repo y un documento de onboarding que nadie había leído desde 2015. A partir de ahí, a remar. Tareas sencillas, mucho copy-paste, y a ver si con el tiempo aprendía algo entre commits. Esto era así en muchas consultoras. Y funcionaba… más o menos.

La IA como junior eterno (que no se va a otra empresa)

Creo que estamos ante una disrupción silenciosa. Me explico:

Al principio, la IA se va a parecer mucho a un perfil junior. Uno que no cobra, no se queja y no se va con la competencia cuando le ofrecen un poco más. Le puedes encargar tareas repetitivas, simples, y poco a poco va mejorando. Pero no porque “aprenda”, sino porque tú, o alguien, le vas dando más contexto, más ejemplos, más datos. En definitiva: lo entrenas.

Ahora bien, en los humanos está claro: si te vas, el conocimiento que tienes se va contigo. Pero con una IA, la pregunta se vuelve jugosa: ¿quién es el dueño del conocimiento que va acumulando?

Y aquí es donde entra el riesgo: si no defines bien desde el principio cómo y para quién aprende esa IA, puedes estar entrenando gratis a un activo que ni te pertenece ni te protege.

¿Quién entrena al entrenador?

Aquí hay dos modelos que se están empezando a perfilar:

  1. Proveedor-entrenador: tú pones la IA, la entrenas, y eso se convierte en tu ventaja competitiva. Es decir, el valor añadido ya no es solo el equipo humano, sino ese “junior digital” que sabe cómo quiere el cliente sus informes, su código, su documentación. Y eso no se lleva el cliente si decide cambiarte por otro proveedor más barato. Touché.
  2. Cliente-propietario: el cliente pone la IA, asume el coste y la entrena según sus procesos. Así, si cambia de proveedor, el conocimiento no se pierde. Porque está en su “junior digital”, que no se va con nadie, ni le ficha otra consultora.

Un nuevo campo de batalla: la propiedad del conocimiento

Este escenario cambia muchas cosas:

  • La lógica de fidelización de clientes.
  • El rol de los proveedores.
  • La propia estructura de costes del conocimiento.

Y todavía no tenemos todas las respuestas. Solo sé que estamos en un punto similar a cuando empezamos a usar máquinas virtuales y se rompieron muchos esquemas. Esto va a ser igual.

No es solo una cuestión técnica, es estratégica: quien entrena mal, replica errores. Y quien entrena sin marco, entrega ventaja competitiva sin saberlo.

Moraleja

Si vas a introducir IA en tus procesos, pregúntate desde ya: ¿quién va a entrenarla? ¿Quién va a pagar ese coste? ¿Y quién se queda con el conocimiento si el proveedor o el cliente cambia?

Aquí es donde entra la paradoja: retener conocimiento solía ser una estrategia… hasta que llegó la IA. Como expliqué en mi artículo [Cuando esconder el conocimiento ya no es estrategia] —donde planteo si tu saber vive solo en ti o también en una IA—, esa dinámica está cambiando radicalmente.

¿Tú cómo lo ves? ¿Quién debería quedarse con el conocimiento en la era IA? Me encantará leerte en LinkedIn.

Diseñado en la cabeza de Iñigo, made in ChatGPT, de momento el conocimiento lo tengo yo, ya veremos por cuanto tiempo 🤷‍♂️