Meat proxy: quién firma lo que la IA escribe

La primera vez que devolví un documento preguntando qué parte de aquello defendía su autor, la respuesta fue un silencio incómodo. El texto era impecable. Estructurado, con su resumen ejecutivo y sus tres recomendaciones. Nadie lo había leído entero, incluido quien lo firmaba.

Eso tiene nombre desde agosto de 2026. Un meat proxy es una persona que reenvía texto, código u otro output generado por IA sin leerlo, comprenderlo ni validarlo. Actúa de relé entre la máquina y el destinatario, y no añade nada por el camino.

El término lo propuso el desarrollador Niklas Gruhn el 3 de agosto de 2026 y se extendió cuando Simon Willison lo documentó ese mismo día. Frank Allenby había usado la forma larga, meat-based llm proxies, en marzo de 2026. Lo interesante no es la palabra. Es que hiciera falta inventarla.

¿Qué hace exactamente un meat proxy?

Es quien hace de cable. La IA produce, la persona reenvía sin detenerse en lo que reenvía, y el trabajo de comprobar si aquello es cierto, si el dato existe y si la recomendación tiene sentido en este contexto se traslada íntegro al que abre el correo sin haber pedido ese encargo. La definición que circula es literal en ese punto: sin leerlo, sin comprenderlo, sin validarlo.

Conviene separarlo de dos cosas con las que se confunde a menudo, porque no es usar IA para redactar, que es sensato y hoy lo hace cualquiera con un plazo encima, ni es delegar una tarea mecánica que nadie en su sano juicio haría a mano teniendo una herramienta delante. Un meat proxy aparece cuando llega una pregunta de criterio, la máquina responde con fluidez, y esa respuesta sale hacia fuera sin que nadie haya ejercido criterio alguno.

La distinción importa porque determina dónde se interviene, y esto es lo que separa una política que funciona de una que solo genera papel: si el problema de fondo fuera la herramienta, se resolvería con una política de herramientas, que es justo lo que están escribiendo muchas compañías ahora mismo. No lo es.

¿Por qué le importa a la empresa y no solo a quien lo recibe?

Porque el coste se transfiere hacia arriba y se vuelve invisible. Quien reenvía aparece como productivo, porque ha despachado el asunto en dos minutos y el sistema registra que lo ha despachado, mientras que quien recibe aparece como lento por dedicar la tarde a reconstruir lo que le han mandado, y ninguna de las dos cosas se corresponde con lo que ha pasado.

Hay medición. BetterUp, junto al Stanford Social Media Lab, encuestó a 1.150 trabajadores de oficina estadounidenses en septiembre de 2025 sobre lo que llamaron workslop, contenido generado por IA que parece bueno y carece de sustancia. El 40% había recibido alguno el mes anterior. Cada incidente costaba cerca de dos horas resolverlo, unos 186 dólares por empleado al mes, más de nueve millones al año en una plantilla de diez mil personas.

La cifra que yo miraría primero no es ninguna de esas. El 53% de quienes lo recibieron declaró molestia y el 22% se sintió ofendido. Las horas se recuperan. La señal que manda un documento sin leer sobre lo que opinas del tiempo de tu interlocutor tarda bastante más en repararse, y no hay presupuesto que la compre.

Todo esto pasa mientras la mayoría de las organizaciones sigue sin extraer valor de su inversión en IA. El estudio de BCG sobre más de 1.250 empresas en 2025 lo cifra con crudeza: solo el 5% obtiene valor a escala y el 60% no obtiene valor material pese a una inversión sustancial (BCG, septiembre de 2025). Ese implementation gap no se explica solo por tecnología mal elegida. Una parte se explica por procesos donde nadie responde de lo que la tecnología produce.

¿Dónde aparece cuando no hay código de por medio?

En casi todas partes, y ahí está el error de diagnóstico más común. El fenómeno se nombró entre desarrolladores, en pull requests y canales de Slack, así que se ha leído como un problema de ingeniería. La ingeniería es donde antes se detecta, porque tiene revisión por pares y pruebas automáticas. No es donde más daño hace.

El daño serio ocurre donde no hay pipeline que valide nada:

Un informe al comité de dirección con una conclusión que nadie puede sostener cuando alguien pregunta de dónde sale el número. Un correo a un cliente que promete un plazo que no existía en ninguna conversación previa. Una especificación funcional que baja a desarrollo con un requisito inventado, y que se construye entera antes de que nadie note que ese requisito no lo pidió el negocio. Una respuesta a un regulador en banca o salud con una interpretación normativa que la empresa no ha validado con nadie.

Los cuatro tienen algo en común. Pasan sin fricción la única revisión que existía en ese circuito, que era la del propio remitente, y la pasan precisamente porque el remitente no revisó nada, de modo que los cuatro llegan a su destino con el membrete de la compañía y con la apariencia intacta de haber sido pensados por alguien.

El código roto se cae. Un informe plausible se aprueba.

¿Qué dice el mercado español sobre esto?

El mercado ya está demandado esto de forma estable. Según el análisis de mercado de Shakers, 2.039 de 31.557 ofertas tech analizdas en España nombran la revisión de código, frente a 1.008 que nombran Copilot (n=31.557, septiembre de 2026). Dos menciones del criterio para juzgar el output por cada mención de la herramienta que lo escribe.

Ese ratio es el dato, y no el volumen. La proporción lleva estable desde agosto: 6,6%, pasando a un 6,5% ahora, mientras el número total de ofertas creció un tercio. Una constante que aguanta un cambio de tamaño así dice más que cualquier crecimiento. No estamos ante una moda reciente. Estamos ante el suelo del mercado.

Conviene decir qué mide ese número y qué no. Mide menciones en el texto de las ofertas y no requisitos formales comprobados uno a uno, que son cosas distintas aunque se parezcan en una hoja de cálculo, así que el verbo honesto aquí es nombran y cualquier otro estaría afirmando más de lo que el dato sostiene. Y no está creciendo en cuota: crece en absoluto porque crece el corpus. Quien quiera vender que cada mes más empresas exigen validar la IA tendrá que hacerlo con otro dato, porque este dice otra cosa.

Hay una señal más pequeña y más precisa. 113 ofertas mencionan explícitamente código generado por IA, el 0,36% del corpus. Es poco. También es el nicho exacto de este problema, y una de ellas, publicada en Barcelona para un rol bautizado como Vibe Engineer, lo formula mejor que cualquier política interna que yo haya escrito: primero el prompt, pero la revisión nunca es opcional, y cada línea que se despliega pasa por ojos humanos. Es un caso suelto y no una tendencia. Pero es el mercado redactando la antítesis del meat proxy en el cuerpo de una oferta.

¿Cómo se controla sin prohibir la IA?

Prohibirla no funciona. Empuja el uso a la sombra y te deja sin trazabilidad justo cuando más la necesitas, con el mismo volumen de output sin revisar y ninguna forma de saber de dónde salió. El control es de proceso.

El primero cuesta cero y es el que más discrimina: responder con tus propias palabras. No es una cuestión de estilo. Un resumen escrito por quien envía, con sus palabras y no con las del modelo, es la única prueba barata de que ha leído, ha entendido y ha validado lo que manda, y tiene la propiedad de que no hay forma de fingirlo sin acabar haciéndolo. Quien no puede resumir lo que manda, no lo ha leído.

El segundo es preguntar por la decisión y no por la herramienta. Da igual si usó un modelo. Lo que importa es si esa persona sabe defender por qué ese enfoque y no otro, si conoce los límites de lo que propone y si ha considerado la alternativa obvia, y todo eso se comprueba con una sola pregunta concreta antes de aprobar nada.

El tercero es dejar de tratar el verde del pipeline como la última palabra. Las pruebas automáticas validan sintaxis y comportamiento, que es mucho y por eso las tenemos, pero este problema es de criterio, y el criterio no lo mide ningún test por bien escrito que esté.

Y el cuarto es explicitar dónde importa. Sin una matriz como esta, cada persona improvisa su propio umbral y la organización no tiene ninguno:

Falta la parte que casi nadie instrumenta: medir en el receptor. La métrica útil no es cuánto produce un equipo. Es cuántas horas dedican tus perfiles senior a reconstruir lo que les llega. Mientras eso no se mida, el coste seguirá siendo invisible por diseño, que es exactamente como lleva funcionando desde que existe.

¿Quién responde cuando el texto lo escribió una máquina?

La misma persona que lo mandó. Esa es toda la política, y cabe en una frase.

La organización que no la escribe acaba con una cadena de responsabilidad rota en un punto muy concreto: el momento en que alguien pulsa enviar sin haber ejercido juicio, y el destinatario asume que hubo juicio porque hay un nombre en el remitente. Nadie miente. Simplemente, el sistema deja de tener el punto de control que todos daban por supuesto.

Esto se agrava con los agentes. El propio estudio de BCG estima que ya representan el 17% del valor generado por IA en 2025, camino del 29% en 2028. Cuanto más output produce la máquina, más depende la cadena de que alguien, en algún punto, responda por él. El trabajo se mueve de los roles a las skills y los agentes, y en ese movimiento la competencia que sube de precio no es escribir más rápido. Es decidir qué sale con tu nombre.

Ahí está el vínculo con el talento certificado en skills IA, que es la forma de saber por adelantado si alguien ejerce ese criterio en lugar de descubrirlo cuando el informe ya está en el comité. Este mismo desplazamiento, visto desde el lado del código, lo tratamos en la pieza sobre el code review como cuello de botella. Y cuando lo que se reenvía sin comprobar es una dependencia de software, el problema deja de ser de calidad y pasa a ser de seguridad, como ocurre con el slopsquatting.

La pregunta que ordena todo esto no es si tu equipo usa IA. Es si, cuando algo sale con el nombre de tu empresa, hay alguien capaz de defenderlo.

Preguntas frecuentes sobre el meat proxy

¿Qué es un meat proxy?

Una persona que reenvía texto, código u otro output generado por IA sin leerlo, comprenderlo ni validarlo, actuando solo como relé entre la máquina y el destinatario. El término lo propuso el desarrollador Niklas Gruhn el 3 de agosto de 2026 y se extendió ese mismo día al documentarlo Simon Willison en su blog.

¿Usar IA para redactar me convierte en un meat proxy?

No. La diferencia está en si ejerces criterio antes de enviar. Redactar con IA, leer el resultado, corregirlo y poder defenderlo es trabajo normal. Reenviar sin leer, cuando lo que se pedía era una decisión, traslada al destinatario la carga de comprobar si aquello es cierto.

¿Cuánto cuesta a una empresa?

BetterUp y el Stanford Social Media Lab lo midieron sobre 1.150 trabajadores de oficina estadounidenses en septiembre de 2025: el 40% recibió contenido de este tipo en un mes, con cerca de dos horas por incidente y unos 186 dólares por empleado al mes. En una plantilla de diez mil personas supera los nueve millones anuales.

¿Es un problema solo de equipos técnicos?

No, y ahí falla el diagnóstico habitual. Se nombró entre desarrolladores porque la ingeniería tiene revisión por pares y lo detecta antes. El daño mayor ocurre donde no hay pipeline: informes a dirección, correos a cliente, especificaciones funcionales y respuestas a un regulador.

¿Se controla prohibiendo el uso de IA?

Prohibirla empuja el uso a la sombra y elimina la trazabilidad sin reducir el output sin revisar. Funciona mejor exigir un resumen en primera persona de lo que se envía, preguntar por la decisión en vez de por la herramienta, y definir por escrito en qué superficies el output sin revisar es aceptable y en cuáles está vetado.

¿Piden las empresas españolas capacidad de revisar lo que genera la IA?

De forma estable. Según el análisis de mercado de Shakers, 2.039 de 31.557 ofertas tech activas en España nombran la revisión de código frente a 1.008 que nombran Copilot (n=31.557, septiembre de 2026). La proporción apenas se mueve desde agosto, así que no es una moda: es el suelo del mercado.