Google ha decidido retirar las Gems de Gemini, sus asistentes personalizados configurables, y reemplazarlas por una funcionalidad llamada skills. El cambio no es cosmetico: afecta a desarrolladores y empresas que habian integrado Gems en sus flujos de trabajo y que ahora tendran que migrar a una arquitectura distinta. Si tu equipo apoyaba parte de su operativa diaria en un asistente configurado con instrucciones fijas, este anuncio te obliga a revisar como lo haras a partir de ahora. Aqui te explicamos que desaparece, que llega en su lugar y como planificar la transicion sin frenar el trabajo.
Que ha pasado y por que importa
Google ha anunciado la eliminacion de las Gems de Gemini para sustituirlas por una nueva funcionalidad denominada skills. Las Gems permitian crear asistentes personalizados con instrucciones predefinidas, un contexto fijo y un comportamiento adaptado a tareas concretas: redactar en un tono determinado, seguir un formato de respuesta o actuar como apoyo en un area especifica. Con la retirada, ese modelo de personalizacion deja de estar disponible y se reorganiza bajo el concepto de skills dentro del ecosistema Gemini.
El impacto directo recae sobre quienes ya habian construido flujos de trabajo apoyados en las Gems de Gemini. No se trata solo de un boton que cambia de sitio: cualquier configuracion guardada, instruccion personalizada o integracion que dependiera de una Gem concreta necesita revisarse y trasladarse a la nueva arquitectura. Para equipos que habian estandarizado ciertas tareas con estos asistentes, la migracion supone trabajo real de reconfiguracion y pruebas.
El movimiento forma parte de una reorganizacion mas amplia de las capacidades de personalizacion de Gemini. Google agrupa bajo skills lo que antes estaba disperso en las Gems, con la intencion de ofrecer un modelo unico de personalizacion en su ecosistema. La logica es coherente con la evolucion habitual de estas plataformas, pero para el usuario que ya tenia algo funcionando, un cambio de nomenclatura y estructura siempre implica coste de adaptacion.
Implicaciones tecnicas de la migracion
La sustitucion de las Gems de Gemini por skills plantea la pregunta clave de toda transicion: hay migracion automatica o hay que rehacer la configuracion a mano. Mientras Google no confirme una ruta de traspaso directa, lo prudente es asumir que parte del trabajo sera manual. Eso significa documentar las instrucciones, el contexto y los ajustes de cada Gem activa antes de que dejen de estar disponibles, para no perder configuraciones que costo tiempo afinar.
Para los desarrolladores, el cambio de arquitectura obliga a revisar cualquier dependencia. Si una Gem estaba conectada a un proceso mas amplio, hay que comprobar como se referencia la nueva skill equivalente y si el comportamiento se mantiene. Los prompts que funcionaban con una Gem pueden requerir ajustes al trasladarse, porque un cambio de estructura interna suele alterar matices en las respuestas. La recomendacion es no dar por hecho que una skill se comportara identico a la Gem que reemplaza sin validarlo.
Este tipo de reorganizaciones son habituales en las plataformas de IA en fase de maduracion. Los nombres, las abstracciones y los limites de personalizacion cambian con frecuencia. Para las empresas, la leccion tecnica es clara: cualquier funcionalidad de un proveedor de LLM puede evolucionar o desaparecer, y conviene no acoplar procesos criticos a una sola caracteristica sin plan de contingencia.
Como pueden aplicar esto las empresas hoy
Lo primero es un inventario. Localiza todas las Gems de Gemini que tu equipo usa de forma habitual y documenta su configuracion completa: instrucciones, tono, contexto y cualquier archivo o dato de referencia asociado. Sin ese registro, la migracion a skills se convierte en reconstruir de memoria algo que ya funcionaba. Hazlo antes de que la retirada sea efectiva.
Segundo, prioriza. No todas las Gems tienen el mismo peso: identifica cuales sostienen tareas recurrentes o procesos que afectan a varias personas, y migra esas primero. Para cada una, recrea la skill equivalente y comparala con el comportamiento anterior en casos reales antes de darla por buena. Evita migrar todo de golpe y a ciegas.
Tercero, aprovecha para revisar el ROI. Si mantener una configuracion personalizada en Gemini exige rehacerla cada vez que Google cambia de modelo, valora si esa tarea concreta justifica la dependencia. En muchos casos si; en otros, quiza convenga documentar el prompt de forma portable para poder reutilizarlo en distintas herramientas. Lo que debes evitar es descubrir que un proceso se ha roto porque nadie sabia que dependia de una Gem que ya no existe.
Analisis Blixel
Cambiar el nombre y la estructura de una funcionalidad que la gente ya usaba tiene un coste que las grandes tecnologicas tienden a minimizar. Para Google, unificar la personalizacion bajo un solo concepto es una decision de producto razonable. Para la PYME que habia configurado media docena de asistentes y los tenia integrados en su rutina, es una tarde perdida reconstruyendo lo que ya tenia. Esa asimetria se repite en casi todas las plataformas de IA, y conviene tenerla presente al decidir cuanto apoyarse en una caracteristica concreta de un proveedor.
La transicion de skills sera probablemente sencilla para quien usaba estos asistentes de forma ocasional, y molesta para quien los habia convertido en parte de su operativa. Ninguna de las dos situaciones es dramatica, pero ilustra una regla practica: cuando personalizas sobre la infraestructura de un tercero, estas alquilando, no comprando. El proveedor puede reorganizar el mobiliario cuando quiera. La defensa no es dejar de usar estas herramientas, sino documentar bien lo que construyes encima para que un cambio de nomenclatura no te deje sin nada. Guarda tus instrucciones en un formato que no dependa de la caja donde las metiste hoy. Asi, la proxima vez que un proveedor decida renombrar sus funciones, la migracion sera copiar y pegar, no empezar de cero.
Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.