El riesgo puede estar en una rutina diaria
La aplicación puede parecer estable y necesitar cada mañana una secuencia manual para funcionar. Si nadie más conoce esa secuencia, una ausencia deja al equipo sin una forma clara de operar. Empezamos por observar esas tareas y preguntar cuáles se podrían ejecutar siguiendo instrucciones.
Para una empresa soriana, esta revisión puede ser más útil que una propuesta inicial de reescritura completa. El objetivo es identificar dependencias personales y técnicas, no asumir que la antigüedad del lenguaje es la causa de todas las dificultades.
Hacer reproducible lo que hoy se resuelve de memoria
Documentamos precondiciones, archivos utilizados y señales de finalización. Si un paso requiere una decisión, especificamos quién la toma y qué información necesita. Evitamos convertir una práctica excepcional en una instrucción general sin revisar sus riesgos.
También comprobamos los permisos. Un sustituto puede conocer el procedimiento y seguir sin poder ejecutarlo porque falta una autorización. La documentación registra esa necesidad sin guardar secretos ni recomendar compartir cuentas personales.
Automatizar solo una secuencia bien comprendida
Cuando un proceso está definido, se puede valorar su automatización o la incorporación de comprobaciones. Primero se determina cómo detectar un fallo y cómo evitar repetir acciones ya completadas. Automatizar una secuencia ambigua solo acelera sus errores.
Si el objetivo incluye .NET, podemos extraer una utilidad o preparar una interfaz de operación. El núcleo COBOL puede conservarse mientras se reduce el trabajo manual. La elección se basa en el proceso concreto y en quién mantendrá el resultado.
IA para apoyar una revisión, no sustituir al operador
Las herramientas de OpenAI o Claude, de Anthropic, pueden ayudar a describir scripts y programas disponibles. Sus propuestas se revisan antes de convertirlas en instrucciones. La herramienta no conoce una precaución que solo existe en la experiencia de quien opera el sistema.
Por eso combinamos el análisis del código con preguntas sobre incidentes anteriores y situaciones excepcionales. Cuando no exista evidencia suficiente, se conserva la duda y se prepara una prueba de alcance limitado.
Una mejora pequeña que tenga un final claro
El primer encargo puede consistir en documentar y ensayar una tarea crítica, corregir su punto más frágil y transferirla a otra persona. Ese resultado es verificable sin prometer la independencia completa del sistema.
Pensemos en una generación periódica de ficheros que requiere pasos manuales. El piloto podría comprobar las entradas y dejar un informe de finalización. Se trata de un escenario explicativo, no de un trabajo realizado para una empresa de Soria.