Crear tu propia aplicación de campo con IA generativa: ¿buena o mala idea?

Es tan sencillo como que un gerente de logística describa lo que necesita en una sola frase a Claude, ChatGPT o Gemini. Treinta segundos después, aparece una interfaz: campos, un botón de «enviar» y una opción para adjuntar documentos. Funciona. El formulario en papel ha pasado a la historia y nadie tuvo que llamar al departamento de TI.

Este escenario ya no es una anécdota aislada. Se está produciendo hoy en un número creciente de empresas que utilizan herramientas de IA generativa dirigidas al consumidor. El instinto es lógico: ¿por qué esperar seis meses y negociar un presupuesto de desarrollo cuando basta una instrucción (prompt) para obtener un resultado visible en cuestión de minutos? De hecho, el uso de la IA generativa casi se ha duplicado en los últimos seis meses, y el 75 % de los trabajadores del conocimiento a nivel mundial ya la utiliza 1.

Un ejemplo concreto: esto ocurrió a gran escala en un importante grupo logístico europeo. Equipos sin perfil técnico comenzaron a crear sus propias aplicaciones y paneles de control con Gemini, sin esperar a obtener una aprobación formal. Al consultarles al respecto, los responsables de TI del grupo nunca cuestionaron la capacidad de sus equipos para generar estas herramientas.

Su preocupación residía en otros aspectos: la gobernanza y la consolidación de datos. Se generaban docenas de herramientas sin supervisión, datos que no se integraban en ningún sistema central y soluciones que dejaban de funcionar en cuanto su creador abandonaba el proyecto.

El diagnóstico del director de TI (CIO) fue tajante: una herramienta creada de forma aislada con IA generativa de consumo puede ser replicada por cualquiera, pero no puede someterse a una gobernanza adecuada. En cambio, lo que el departamento de TI sí puede aceptar es el uso de IA generativa integrada en una plataforma con gobernanza establecida.

Programar nunca fue la parte más difícil

Probablemente ya hayas visto cómo funciona, o incluso hayas creado una aplicación tú mismo. Describes lo que necesitas a Claude, ChatGPT o Gemini y obtienes una aplicación funcional. Eso es indiscutible y seguirá siéndolo: los modelos de IA generativa mejoran cada pocos meses y la brecha que aún existe entre el código escrito por la IA y el escrito a mano continúa cerrándose.

La realidad es que programar una aplicación nunca fue el paso más difícil en un proyecto de digitalización de operaciones. Es el paso más visible, aquel que se puede mostrar en una demostración de tres minutos. Pero eso no lo convierte en el más decisivo.

¿Por qué? Porque, para un equipo operativo, una aplicación móvil no es una pantalla que aparece una sola vez. Debe resistir el paso del tiempo y las circunstancias: la marcha de quien la creó, un almacén sin cobertura, una actualización del sistema operativo del teléfono, una auditoría de seguridad o tres años de crecimiento de la empresa. El código generado a partir de una instrucción (prompt) no resuelve ninguna de estas cuestiones; simplemente las plantea más adelante, a menudo en el peor momento, cuando ya no queda nadie para responderlas.

El iceberg oculto tras cada aplicación desarrollada internamente

La IA generativa produce un resultado visible en cuestión de minutos: esa es la punta del iceberg, aproximadamente el 20% de lo que hace que una aplicación de campo funcione realmente a largo plazo y a escala organizativa. El 80% restante permanece bajo la superficie —invisible en la demostración— y es precisamente lo que más subestiman quienes desarrollan estas aplicaciones.

Gobernanza y riesgo de dependencia de una persona clave

Una aplicación creada por una sola persona, utilizando su propia cuenta de Claude, Gemini o ChatGPT, deja a la organización sin nada sobre lo que trabajar: sin especificaciones, sin documentación y sin una segunda persona capaz de hacerse cargo si fuera necesario. El único registro existente es el historial de chat de ese individuo.

La aplicación sobrevive mientras esa persona permanezca en la empresa. El día que cambia de puesto o se marcha, la aplicación queda huérfana: nadie se atreve a tocarla, y mucho menos a seguir desarrollándose, por miedo a romper un mecanismo que nadie comprende realmente.

A escala organizacional, esto debe multiplicarse por cada empleado que, una tarde, decidió probar un prompt para resolver un problema propio.

Esta es precisamente la tendencia que Gartner anticipó en 2021 3:

No se trata de un detalle menor. Cada aplicación creada fuera de la supervisión del departamento de TI representa un nuevo silo de datos, una fuente de informes que no se integra en ningún sistema central y un riesgo de cumplimiento normativo que nadie ha evaluado.

He aquí la observación que hizo cambiar la mentalidad de un CIO: pasó de desarrollar soluciones internamente a optar por una plataforma bajo gobernanza:

Una aplicación diseñada para la oficina no sobrevive en el trabajo de campo

La IA generativa de consumo produce lo que mejor conoce: interfaces tipo «software de oficina» (campos para rellenar, casillas para marcar, texto para escribir). Eso es casi lo opuesto a lo que necesitan un técnico, un repartidor o un auditor de QHSE en el terreno.

Un operario de almacén lleva guantes. Un técnico trabaja bajo una luz solar intensa, con una pantalla apenas legible. Un repartidor sostiene un paquete con una mano y el teléfono con la otra. Ninguno de ellos tiene tiempo, ni una mano libre, para rellenar un formulario diseñado como una hoja de cálculo.

Lo que requiere el trabajo de campo es lo contrario a la entrada manual de datos:

• una captura guiada en la que un escáner de códigos de barras,
• un sistema OCR o un escáner de visión sustituyan a la escritura manual,
• y donde cada paso esté diseñado para completarse en dos segundos con un solo dedo, sin necesidad de teclado ni párrafos de texto.

Este tipo de diseño no puede improvisarse mediante un prompt ni crearse desde un escritorio; se construye tras años observando a los equipos operativos trabajar sobre el terreno.

Igual de crucial es la fiabilidad en condiciones reales. Una demostración funciona con la red Wi-Fi de la sede central. El trabajo de campo implica sótanos de almacenes sin cobertura, rutas rurales en zonas muertas y equipos que no pueden detener su labor porque una solicitud ha agotado el tiempo de espera. El modo sin conexión no es una función que se añada a posteriori: es toda una arquitectura (almacenamiento local, colas de sincronización, gestión de conflictos, recuperación ante fallos parciales) que tampoco puede generarse simplemente mediante una instrucción de IA. Debe construirse.

Descubra cómo Chronopost utiliza WizyVision para realizar inventarios de sus unidades refrigeradas.

Actualizaciones, distribución, integraciones, seguridad: el resto del iceberg

Estos dos primeros puntos son los que más subestiman los responsables de decisiones operativas. Pero el iceberg va aún más allá, por debajo de la línea de flotación.

Desplegar una aplicación de desarrollo propio en 50, 200 o 1.000 dispositivos de campo implica crear una cuenta de desarrollador, publicarla en la App Store (iOS) o en Google Play Store y superar sus ciclos de revisión cada vez que haya cambios; o bien gestionar la distribución mediante una solución MDM empresarial, lo que en cualquier caso conlleva la firma de la aplicación y la gestión de versiones.

Su mantenimiento implica:

• Lanzar una nueva versión sin interrumpir el acceso de los usuarios activos;
• Adaptarse a una actualización del sistema operativo que rompe una dependencia;
• Corregir una vulnerabilidad de seguridad que no puede esperar al siguiente sprint.

En una plataforma gestionada, nada de esto supone un proyecto nuevo: la aplicación ya está instalada y una nueva versión es simplemente un cambio de configuración, no un envío a la tienda de aplicaciones.

Asimismo, una aplicación que no se comunica con ningún otro sistema no es más que un formulario: sin conexión con el ERP, el WMS o las herramientas de generación de informes, los datos recopilados no se consolidan en ninguna parte. Simplemente se suman a la carga de reintroducción manual de datos que la aplicación pretendía eliminar. Y la integración es, precisamente, la tarea que nunca termina en los desarrollos propios: autenticación, límites de tasa de peticiones, gestión de errores, evolución de esquemas de datos, monitorización... la lista crece a medida que lo hace el sistema.

La seguridad y el cumplimiento normativo completan el panorama: alojamiento, cifrado, gestión de acceso basada en roles, registros de auditoría, certificaciones (ISO 27001, SOC 2...). Nada de esto es un detalle menor para un departamento de TI en sectores regulados como la energía, la sanidad, el transporte o las finanzas.

Por este motivo, WizyVision cuenta con la certificación ISO 27001. Abordaremos este tema con mayor profundidad en un futuro artículo dedicado a la seguridad y el cumplimiento normativo.

En otras palabras, las aplicaciones desarrolladas internamente no solo conllevan una serie de riesgos, sino que también requieren la intervención del equipo de TI para su mantenimiento, seguridad, cumplimiento normativo y desarrollo continuo. Un equipo de TI que, en la mayoría de los casos, no participó en su creación inicial. Se trata, a todas luces, de una carga de trabajo adicional.

La verdadera prueba: ¿qué aspecto tiene el código al cabo de un año?

Supongamos, a efectos de este análisis, que el código generado funciona a la perfección el primer día. Aun así, debe resistir el paso del tiempo.

Esto se aplica incluso a equipos que cuentan con procesos de revisión de código, herramientas de calidad y procedimientos de validación. La situación es necesariamente más crítica en el caso de una aplicación creada por un único usuario de negocio que trabaja en solitario, sin una segunda opinión, sin disciplina de repositorios y sin revisiones. El código funciona el primer día; lo que se deteriora silenciosamente es todo aquello que carece de un responsable.

Un estudio publicado en julio de 2026 por GitClear y GitKraken 6, que analiza 623 millones de cambios de código reales realizados entre 2023 y 2026, aporta un dato revelador al respecto, incluso para los equipos de desarrollo profesionales que cuentan con las herramientas y la disciplina adecuadas.

El coste real nunca aparece en la demostración

Durante décadas, la investigación en ingeniería de software ha convergido en una misma conclusión: el desarrollo inicial nunca representa la mayor parte del coste de un software a lo largo de su ciclo de vida. Diversos análisis del sector coinciden en un orden de magnitud similar: se estima que el mantenimiento supone entre el 50 % y el 80 % del coste total del ciclo de vida del software, frente al 20 %-50 % del desarrollo inicial, dependiendo del contexto 4.

The Standish Group documenta un patrón relacionado en su informe CHAOS 5:

Ninguno de estos costes aparece en una demostración rápida. Surgen, uno a uno, en los meses posteriores al lanzamiento: en forma de incidencias, correcciones urgentes y solicitudes de cambios que nadie sabe muy bien cómo gestionar. La persona que mejor domina la solución se convierte, en la práctica, en la encargada permanente del mantenimiento de una aplicación de la que nunca aceptó ocuparse. Esta responsabilidad no figura en la descripción del puesto de trabajo de nadie.

La misma instrucción, un «día dos» radicalmente distinto

Como ya se ha señalado, la IA es realmente eficaz a la hora de escribir código. Por eso, la consola de administración de WizyVision permite generar una aplicación a partir de una simple descripción en lenguaje natural. El instinto de utilizar instrucciones (prompts) es acertado; lo que lo cambia todo es la base sobre la que se construye.

Dos instrucciones idénticas, dos resultados radicalmente distintos, según la base utilizada.

Si se envía a una IA generativa independiente, sin una plataforma que la respalde, una instrucción que genera código bruto te deja con todo lo que queda «bajo la línea de flotación»:

• Sincronización sin conexión;
• Distribución;
• Actualizaciones;
• Permisos;
• Integraciones;
• Gobierno de datos...

Todo eso pasa a ser problema tuyo: debes construirlo pieza a pieza y sin red de seguridad.

Sin embargo, al enviarla a la consola de WizyVision, esa misma instrucción llega a un entorno donde ya existen el modo sin conexión, la distribución, los permisos, las integraciones y el gobierno de datos. La configuración se convierte en la propia documentación: la aplicación es un esquema declarativo (campos, reglas, flujos de trabajo, estados) que cualquier persona con los permisos adecuados puede leer y editar, a diferencia del código cuya lógica reside únicamente en la memoria de su autor. El control de acceso, los roles y los registros de auditoría se centralizan una sola vez, en lugar de tener que reinventarlos en cada proyecto.

La misma instrucción. El mismo instinto inicial. Pero un «día dos» radicalmente distinto.

Comparativa: una aplicación independiente generada por IA frente a una aplicación generada por IA en una plataforma gobernada

¿Por qué elegir una plataforma robusta en lugar de una aplicación generada internamente con IA? A continuación, analizamos criterio por criterio qué diferencia a una aplicación creada a partir de una instrucción (prompt) aislada de otra desarrollada con la misma instrucción pero desplegada en una plataforma diseñada para operaciones de campo.

Cuándo tiene sentido crear tu propia aplicación con IA

Dicho esto, hay situaciones en las que generar tu propia aplicación mediante un prompt es la decisión correcta:

• Un uso puntual real, para una necesidad concreta y de una sola vez;
• Una herramienta interna desechable, sin pretensión de durar más de un trimestre;
• Una tarea sin componente de campo ni requisito de funcionamiento sin conexión, que simplemente sustituye a una hoja de cálculo.

En estos casos concretos, el tiempo y el coste de una plataforma pueden no estar justificados. Por tanto, la pregunta no es si la IA puede construir la aplicación —en la mayoría de los casos, sí puede—. La pregunta es si esta aplicación debe sobrevivir a su creador, a las condiciones de campo y al año que viene. Si la respuesta es sí, la parte difícil empieza exactamente donde termina el prompt.

Conclusión: la programación nunca fue la parte más difícil

Las plataformas no-code de nueva generación y la IA generativa de consumo tienen algo en común: han puesto la creación de una primera versión de una aplicación al alcance de cualquier empleado operativo. No es algo contra lo que luchar, sino una señal que merece la pena atender.

Si tus equipos de campo ya están utilizando prompts para sus propias herramientas, no se trata de insubordinación: es la prueba de que existe una necesidad real y de que el instinto de tu equipo es acertado. El objetivo no es detenerlos, sino proporcionarles una base sólida sobre la cual desarrollar esas soluciones: una aplicación segura y gobernada, robusta para el trabajo en campo, integrada con el resto de tus sistemas de información y diseñada para perdurar más allá de quien la creó.