Crear software de gestión con IA: errores y comprobaciones

De la primera demo al trabajo diario: doce puntos de control, un taller ficticio y ejemplos para comprobar cálculos, datos, accesos, costes y recuperación.

Se abre una ficha de cliente y toma forma un presupuesto: el software de gestión que creas con IA empieza a ser real. Lo que importa el lunes por la mañana se ve menos: el importe correcto, el destinatario adecuado, información que se conserva y una forma de seguir trabajando después de un fallo.

Esta guía sigue un caso ficticio: el taller de Camille, una pequeña empresa que quiere sustituir su hoja de seguimiento de presupuestos. Camille prepara las ofertas; Sam organiza los trabajos. Quieren encontrar clientes, seguir las respuestas y dejar de copiar la misma información. No son clientes de Maestro ni un proyecto que hayamos probado.

Cada dificultad lleva a una comprobación concreta. Puedes plantear estas preguntas sin saber programar. Algunas respuestas requieren una persona técnica, sobre todo antes de utilizar datos reales de clientes o abrir la aplicación a varias personas.

1. Construir a partir de una petición demasiado vaga

«Quiero gestionar mis presupuestos» deja muchas decisiones abiertas. ¿Necesitas encontrar un documento, calcular su importe, enviarlo o seguir su aceptación? La IA puede proponer algo aparentemente coherente que no encaje con tu manera de trabajar. La primera señal es sencilla: cada persona describe de forma distinta lo que debe hacer la aplicación.

Camille precisa la necesidad: al terminar el día, quiere ver las ofertas enviadas hace más de una semana y decidir cuáles requieren seguimiento. En esta primera versión no necesita emitir facturas ni cobrar pagos. Ese límite concentra la primera versión en una función completa.

Escribe el proceso actual con un ejemplo inventado: un cliente pide un trabajo, Camille prepara una oferta, el cliente responde y Sam recibe la fecha prevista. Anota dónde llega la información, quién la modifica y qué demuestra que cada paso ha terminado. Incluye una excepción, como una oferta cancelada.

Pide a la persona que realizará la tarea que lea el texto. Si Sam entiende algo distinto, corrige el documento antes que la pantalla. La guía de requisitos sin tecnicismos ayuda a reunir estas reglas sin convertir el proyecto en un expediente interminable.

2. Confundir una demostración con una aplicación lista

Una demostración muestra un recorrido elegido. Puede usar ejemplos ya rellenados, simular un envío o conservar la información solo durante la visita. No tiene por qué ser un defecto: sirve para hablar de una idea. El problema empieza cuando le confías trabajo sin saber qué funciona realmente.

Camille crea una oferta y ve una confirmación. Cierra la aplicación, vuelve a abrirla y busca el documento. Este pequeño recorrido revela algo que una pantalla atractiva no demuestra: ¿sigue ahí lo que ha introducido? También compara la oferta guardada con los datos que acaba de escribir.

Prueba el recorrido completo

• Crear un cliente ficticio y una oferta que le corresponda.
• Cerrar y volver a abrir la aplicación, y encontrar ambos registros.
• Cambiar un dato, guardarlo y comprobar el documento generado.
• Cancelar una oferta y observar en qué listas aparece.

Pide a quien construye la herramienta que distinga lo operativo, lo simulado y lo que falta. Conserva la respuesta en el proyecto. Un mensaje de «enviado» debe corresponder a un resultado que puedas observar con una dirección de prueba que controles. Si no es así, el envío sigue pendiente de comprobar y no debe usarse para un seguimiento real.

3. Creer un resultado anunciado sin examinar la prueba

Una IA puede anunciar que todo funciona después de comprobar solo una parte del recorrido. Una prueba automática también puede repetir la misma regla errónea que el programa. Si ambos aplican un descuento al transporte cuando querías excluirlo, el indicador verde no responde a tu necesidad.

En nuestro ejemplo ficticio, el trabajo cuesta 200 €, el transporte 30 € y el descuento del 10 % solo afecta al trabajo. El importe esperado antes de impuestos es, por tanto, 210 €: 180 € del trabajo y 30 € del transporte. Es un ejemplo de cálculo, no una plantilla fiscal o contable para presupuestos.

Escribe ese resultado antes de pedir la modificación. Compara después el importe en pantalla, el guardado y el documento destinado al cliente. Añade una oferta sin descuento y otra sin transporte. Así comparas varias situaciones con un resultado conocido.

Pregunta también qué controles no se han realizado. Un límite escrito ayuda a decidir; una certeza vaga no. La guía sobre las pruebas antes del código explica cómo conservar estos ejemplos para reutilizarlos en las siguientes modificaciones.

4. Confundir el inicio de sesión con la protección de los registros

Una pantalla de acceso no explica quién puede consultar o modificar cada cosa. En el taller, Sam necesita la agenda y los datos de contacto necesarios para el trabajo. Camille puede querer reservar cierta información comercial a otra función. Expresa ese reparto antes de pedir simplemente «cuentas de usuario».

Prepara cuentas y registros ficticios en un entorno de prueba autorizado. Para cada función, escribe qué información se ve y qué acciones se permiten. Pide a la persona técnica que compruebe esa lista, también cuando una acción deba rechazarse. No hagas estas pruebas sobre cuentas reales de clientes.

OWASP recomienda limitar los permisos a lo necesario y comprobar cada solicitud donde se protegen los datos. Ocultar un botón no sustituye ese control.

Camille ya tiene una pregunta precisa: «Con una cuenta de prueba para intervenciones, ¿podemos consultar las citas permitidas sin acceder a la información comercial reservada? ¿Puedes documentar la comprobación?». Sin respuesta, pospón la incorporación de registros reales.

Prepara también la salida de una persona: ¿quién retira su acceso y quién lo comprueba? Identifica al propietario de la cuenta de administración. Si todo depende de una dirección de un proveedor que no está disponible, has encontrado una dependencia que resolver antes del lanzamiento.

5. Suponer que «local» significa «ningún dato sale»

Dónde se conserva el proyecto, dónde la IA procesa una petición y dónde la aplicación final guarda sus datos son tres preguntas distintas. Una herramienta instalada en tu ordenador puede contactar con un proveedor de IA. La aplicación que ayuda a construir también puede utilizar servicios remotos.

Camille no necesita enviar su archivo real de clientes para explicar la forma de un presupuesto. Prepara nombres, direcciones e importes inventados. Conserva las dificultades habituales: dos personas con el mismo nombre, un campo vacío y una oferta cancelada. Los datos de prueba siguen siendo útiles sin reproducir sus expedientes.

La CNIL aconseja elegir la IA según el uso y los datos transmitidos. Antes de enviar información real, pide que una persona competente revise las condiciones del proveedor y las reglas de tu actividad.

Pide una explicación comprensible: ¿qué archivos puede leer el asistente, qué elementos pueden transmitirse, a qué proveedor y con qué ajustes? Una captura para pedir ayuda ya puede contener un nombre o una dirección. Revisa también lo que adjuntas a una conversación.

No pegues una contraseña ni una clave de acceso en el documento de requisitos. Pide a la persona técnica que prepare su almacenamiento y sustitución. Si un secreto se ha compartido por error, solicita que se revoque y sustituya la clave o se cambie la contraseña afectada. Borrar el mensaje no elimina un acceso ya obtenido.

6. Añadir una función sin volver a comprobar las anteriores

Una modificación puede afectar a varios sitios: la introducción de datos, el cálculo, el documento y las listas de seguimiento. El síntoma habitual es una función que por fin va bien junto a otra que ha dejado de hacerlo. Se descubre tarde si nadie repite el recorrido habitual después del cambio.

Camille pide un descuento sobre los trabajos. También precisa que el transporte sigue igual, que una oferta sin descuento conserva su total y que el estado de aceptación no cambia. Estos puntos describen lo que debe seguir siendo cierto alrededor de la novedad, sin dejar que el asistente lo adivine.

Una ficha breve de modificación

• Cambio solicitado: un descuento sobre los trabajos.
• Reglas conservadas: transporte, importes anteriores y estados.
• Ejemplos que repetir: oferta estándar, oferta con descuento y oferta cancelada.
• Decisión: aceptar la versión o pedir una corrección concreta.

Antes de intervenir, pide conservar un estado del proyecto que se pueda recuperar. Después, realiza las comprobaciones en una copia de trabajo. La guía de correcciones que rompen otra cosa explica esta costumbre. Si volver atrás afecta a datos introducidos desde el cambio, pide que te expliquen su tratamiento: recuperar una versión anterior del código no recupera automáticamente el trabajo realizado entre medias.

7. Presupuestar la creación y olvidar el funcionamiento diario

La suscripción no representa necesariamente el coste completo. El taller quizá deba pagar IA, alojamiento, mensajes o una intervención de mantenimiento. El tiempo que Camille dedica a comprobar reglas y corregir datos también forma parte del esfuerzo real.

Separa los gastos de construcción de los necesarios para seguir trabajando. Una aplicación puede costar poco durante una demostración y más cuando aumentan los usuarios, documentos o peticiones a un servicio. Evita extrapolar el precio de una prueba breve a todo un año sin indicar las hipótesis.

• Construcción: definición, pruebas de IA, revisiones, comprobaciones y ayuda técnica.
• Funcionamiento: servicios utilizados, almacenamiento, copias de seguridad y asistencia.
• Evolución: nuevas peticiones, adaptación a servicios externos y controles tras los cambios.

Camille fija un punto de decisión antes de cada nuevo bloque de trabajo. Anota el gasto observado durante la prueba, lo conseguido y lo que queda por pagar. Un límite de presupuesto escrito ayuda a elegir entre continuar, reducir la petición o pedir consejo; no crea un tope técnico de gasto en el proveedor.

Comprueba por separado las alertas, los límites que realmente bloquean el consumo y las condiciones de facturación del servicio elegido. La guía del presupuesto de una aplicación ayuda a preparar esa conversación.

8. Tener los archivos sin saber qué se puede retomar

La propiedad del código, los derechos sobre los elementos utilizados y la capacidad de volver a poner en marcha la aplicación merecen respuestas separadas. Tener una carpeta de archivos no indica, por sí solo, qué cuentas hacen falta ni qué condiciones acompañan a una biblioteca, una imagen o un servicio.

Pide un inventario del proyecto: código, documentos, componentes añadidos, servicios y accesos necesarios. Para cada elemento ajeno, conserva su procedencia y la información de licencia disponible. Encarga la revisión de condiciones dudosas a una persona competente antes de un uso comercial; esta guía no determina los derechos de tu proyecto.

Camille pide después un relevo concreto: «Si otra persona retoma la herramienta, ¿qué debo entregarle para que pueda arrancarla con datos de prueba?». La respuesta debe describir archivos y pasos. «Todo te pertenece» no sustituye esa preparación práctica.

La guía de propiedad y entrega del código profundiza en esa distinción. Mantén las cuentas importantes bajo el control de la empresa y documenta quién puede administrarlas. El objetivo es permitir un relevo sin depender del recuerdo de una conversación larga con un asistente o proveedor.

9. Descubrir demasiado tarde que no se preparó la salida

Una exportación y una copia de seguridad responden a necesidades diferentes. La exportación ayuda a consultar o trasladar información. La copia debe permitir recuperar un estado utilizable con los elementos necesarios. Un archivo descargado puede carecer de adjuntos, relaciones entre registros o ajustes.

En el ejemplo de Camille, se preparan tres clientes ficticios, sus ofertas y algunos documentos adjuntos. La persona técnica realiza una exportación y explica cómo cada oferta sigue vinculada a su cliente. Una lista de nombres no basta si los importes y el historial de aceptación desaparecen por el camino.

La ANSSI recomienda preparar la restauración y probarla periódicamente. También recuerda incluir lo necesario para reinstalar y configurar las aplicaciones. Tener una copia de seguridad no demuestra, por sí solo, que la recuperación funcione.

Pide una prueba separada de la herramienta cotidiana: poner en marcha una copia, encontrar los registros esperados y anotar lo que falta. Camille comprueba el contenido del negocio; una persona técnica organiza la operación sin sobrescribir los datos de trabajo. Conservad por escrito los pasos y el resultado.

Define por último cuánta pérdida de trabajo y cuánto tiempo de interrupción admite tu actividad. Perder un día de entradas puede ser asumible en una prueba y mucho menos tras el lanzamiento. Si sustituyes una herramienta existente, prepara el traslado de datos de Excel antes de retirar el acceso anterior.

10. Prometer trabajo en equipo sin organizar cómo compartir

Que una aplicación funcione en un ordenador no demuestra cómo trabajarán dos personas juntas. Pueden usar copias distintas, sobrescribir una modificación o ver estados diferentes. Con ayuda de quien diseña la herramienta, decide dónde estará la información compartida y cómo accederá cada persona.

Camille y Sam abren una oferta ficticia. Camille cambia la fecha prevista mientras Sam actualiza el contacto. ¿Qué información debe conservarse? ¿Cómo saben que otra persona ha modificado el registro? La expresión «aplicación colaborativa» no responde a esas preguntas.

Pregunta también qué sucede sin conexión y al volver la red, si ese uso está previsto. Quizá haya que esperar a reconectar para introducir datos. Los usuarios deben comprender esa decisión y debe encajar con su trabajo real.

Una aplicación local no elimina estas decisiones ni demuestra que Maestro ofrezca colaboración entre usuarios sin servidor. Distingue siempre las capacidades de la herramienta de construcción de las de tu futura aplicación. Pide que se documenten el intercambio, las cuentas y las modificaciones simultáneas antes de elegir la solución.

11. Lanzar sin responsable para lo que viene después

El primer día de uso abre nuevas preguntas: ¿quién recibe los errores, quién decide si un problema bloquea el trabajo y quién puede corregir la aplicación? Sin un responsable disponible, una dificultad corriente puede paralizar el taller.

Empieza por un alcance que puedas observar. Camille prueba el seguimiento con datos ficticios y organiza un uso limitado tras las comprobaciones adecuadas. En cada etapa, identifica claramente la herramienta de referencia para evitar que dos listas contradictorias se utilicen a la vez.

Prepara instrucciones de contingencia comprensibles: a quién comunicar un error, qué información anotar sin exponer datos confidenciales y cómo continuar el trabajo autorizado. Planifica también las actualizaciones de componentes con la persona técnica. Una aplicación terminada no es necesariamente algo que puedas olvidar durante años.

El tratamiento de datos sensibles, los pagos y las actividades reguladas requieren un acompañamiento adecuado a sus consecuencias. Elegir una primera versión pequeña ayuda a aprender; no reduce automáticamente las consecuencias de un error sobre los datos que trata.

12. Conservar una ficha de decisión antes de continuar

Para tu propio proyecto, copia las siguientes líneas y complétalas con alguien que conozca el trabajo. Sustituye «está bien» por un resultado observable, una fecha o una incógnita que resolver.

• Uso prioritario: ¿qué acción debe hacerse más sencilla y para quién?
• Regla esencial: ¿qué resultado calculamos o definimos de antemano?
• Prueba: ¿qué recorrido completo hemos probado realmente?
• Datos y accesos: ¿qué comprobamos y quién resuelve las incógnitas?
• Gastos: ¿qué importe o situación obliga a tomar una nueva decisión?
• Recuperación: ¿cuándo se restauró una copia y con qué resultado?
• Continuidad: ¿quién recibe los incidentes y quién autoriza la puesta en marcha?

En el taller ficticio, una pantalla lograda basta para seguir hablando de la necesidad. No basta para enviar ofertas reales. Cada prueba añade una razón concreta para avanzar; cada incógnita importante señala trabajo pendiente. Puedes pedir esa forma de rendir cuentas tanto a un asistente como a un proveedor.

Maestro reúne la definición, la construcción y las validaciones del proyecto. Su beta para Mac está disponible por invitación: la aplicación es gratuita y el uso de IA se paga aparte. Consulta la presentación de Maestro para ver las condiciones actuales. Este marco ayuda a organizar las conversaciones; decidir utilizar tu software depende de las comprobaciones apropiadas para tu actividad.

Volver al índice