ENTREGABLE C: EL FACTOR DE INTELIGENCIA ARTIFICIAL Y ÉTICA (EVALUACIÓN CRÍTICA)

• Asignatura: Sistemas de Información
• Institución: Facultad Experimental de Ciencias y Tecnología (FaCyT) — Universidad de Carabobo
• Autor: Guillermo Cedeño
• Tecnología de Asistencia: Agentes de Antigravity (Socio de Co-creación Lógica y Arquitectónica)
• Fecha: Julio 2026

1. Bitácora de Uso de IA: Enfoque, Prompts y Toma de Decisiones

El desarrollo de la plataforma FaCyT Events se concibió bajo un modelo de co-creación híbrido. En lugar de delegar la escritura pasiva de código estático, los agentes de IA funcionaron como consultores técnicos integrados al flujo de trabajo, asistiendo en el diseño de la arquitectura relacional, la implementación de reglas de negocio en el backend y el desarrollo de interfaces responsivas y accesibles en Next.js.

1.1 Metodología de Prompts Utilizada

La interacción con la IA se estructuró mediante prompts contextualizados de asignación de rol, restricciones de dominio, contratos técnicos y resolución iterativa de problemas:

• Prompt de Diseño de Persistencia (PostgreSQL + Drizzle):
> *"Actúa como un Administrador de Base de Datos relacionales experto en PostgreSQL 17 y Drizzle ORM. Necesito diseñar el esquema físico de una base de datos para la gestión de eventos de FaCyT. Genera la estructura de tablas (users, spaces, events, registrations, certificates, date_change_requests y la tabla intermedia de asignación de moderadores moderator_requests). Asegúrate de que las claves foráneas tengan restricciones estrictas de integridad referencial y de definir los índices óptimos para consultas temporales rápidas."*

• Prompt de Validación Horaria (La Golden Rule en NestJS):
> *"Actúa como desarrollador Senior en NestJS 11. Genera el servicio EventsService encargado de crear y actualizar eventos. Implementa un método que verifique mediante una consulta de Drizzle ORM que no existan conflictos horarios en el mismo espacio físico para eventos aprobados, aplicando la condición clásica de solapamiento: un nuevo evento no puede iniciar antes de que termine uno existente, ni terminar después de que inicie uno activo en el mismo space_id."*

• Prompt de Escáner QR de Entrada Continuo y Cooldown:
> *"Actúa como frontend lead de Next.js. Diseña la lógica del lector de código QR de asistencia para el Moderador. Necesito que al detectar una lectura válida de un QR no desmonte la cámara, sino que pause el procesamiento y abra un modal detallado del participante. Adicionalmente, implementa una protección de cooldown de 4 segundos con referencias de React para evitar que, tras cerrar el modal, el lector vuelva a procesar inmediatamente el mismo código QR y provoque errores continuos en bucle."*

• Prompt de Notificaciones por Email y Plantillas Dinámicas:
> *"Actúa como Arquitecto de Software experto en NestJS. Necesito diseñar un servicio de correos electrónicos informativos (MailsService) acoplado a Nodemailer. El sistema debe reaccionar de forma automática ante eventos del ciclo de vida de la aplicación: notificar al Organizador cuando su solicitud es aprobada o rechazada (incluyendo el motivo), despachar el código QR inline en formato PNG adjunto al inscribirse, advertir de la cancelación de una actividad, y enviar el diploma en PDF. Diseña las plantillas HTML con un estilo minimalista y profesional usando CSS inline compatible con clientes de correo estrictos."*

Prompt:

> *Sumados a multiples prompts de creación del vistas, correcciones visuales y de lógica de negocio, cambios pequeños, y resolución de errores, los cuales no son relevantes para el entregable, sin embargo son la mayoría.*

1.2 Proceso de Filtrado y Toma de Decisiones

Cada propuesta generada por la IA fue sometida a un riguroso proceso de control de calidad por parte del desarrollador:

• Decisiones Aceptadas:
* Diseño modular de controladores y servicios propuesto para NestJS.
* Configuración de contenedores Docker aislados para PostgreSQL 17.
* Implementación del estado global de Zustand para el escáner QR en Next.js.
* Estructura en memoria para la compilación de certificados académicos en PDF con pdfkit.
* Implementación de skeletons de carga para sustituir spinners y mejorar la estética UI.

• Decisiones Descartadas o Modificadas:
* Almacenamiento de imágenes: La IA sugirió utilizar un servicio en la nube (Cloudinary), el cual fue descartado debido a las restricciones de presupuesto académico de la facultad; en su lugar, se forzó al sistema a procesar subidas físicas locales mediante Multer en la VPS.
* Validación de Aforo: La IA propuso un bloqueo estricto (HTTP 400) cuando el aforo estimado superaba la capacidad del espacio. Esto se modificó para permitir la solicitud, pero mostrando una advertencia blanda interactiva (useConfirm) para que el Organizador tomara una decisión consciente.
* Bloqueo de Solicitudes: La IA diseñó el algoritmo de colisión horaria bloqueando solicitudes en estado solicitado. Se descartó esta lógica para permitir la coexistencia de propuestas en revisión, restringiendo el bloqueo estrictamente a eventos ya aprobados.

2. Control Crítico de la IA: Errores, Alucinaciones y Verificación

Se documenta la capacidad del desarrollador para auditar, detectar y corregir desviaciones lógicas y técnicas provocadas por las herramientas de IA durante el desarrollo y despliegue del sistema:

2.1 Caso 1: Alucinación Sintáctica en la API de Drizzle ORM

• El Error de la IA: Al solicitarle estructurar la consulta SQL de solapamiento temporal para la "Golden Rule" en NestJS, el agente alucinó con la existencia de métodos de consulta relacional cruzados directos de alto nivel en Drizzle ORM que solo están presentes en otros ORMs. El código provisto por la IA intentaba realizar una consulta directa usando funciones inexistentes del tipo findOverlappingEvents(...), provocando fallos inmediatos de compilación en el tipado de TypeScript.
• Detección y Corrección: El desarrollador identificó el fallo al analizar los logs del compilador de TS. La corrección se aplicó reescribiendo la lógica con los operadores de comparación lógica nativos y estrictos de Drizzle (and, eq, lt, gt), estructurando la consulta SQL pura bajo la condición de solapamiento exacto de rangos temporales.

2.2 Caso 2: Desfase de Zonas Horarias (Timezones) en Docker

• El Error de la IA: El servicio de validación de eventos generado por la IA guardaba y consultaba las horas en formato local de la máquina en desarrollo. Sin embargo, al dockerizar la base de datos PostgreSQL 17 y desplegar el backend NestJS en la VPS bajo PM2, el servidor VPS utilizaba la hora del sistema configurada en UTC neutro. Esto provocó una "alucinación lógica": el motor de validación permitía el registro de eventos que colisionaban físicamente en el Auditorio de la FaCyT porque calculaba un desfase de 4 horas respecto a la hora local de Venezuela.
• Detección y Corrección: El desarrollador detectó la deconexión al auditar los registros y logs del contenedor de PostgreSQL (docker logs facyt-postgres) y notar que las inserciones SQL se registraban con desfase. La solución consistió en dos pasos:
1. Configurar los campos de fecha en el esquema de Drizzle utilizando de forma estricta el tipo timestamp({ withTimezone: true }) para forzar a PostgreSQL a guardar las marcas en formato ISO 8601 con zona horaria explícita.
2. Ajustar la validación en NestJS para comparar fechas normalizadas utilizando formateos nativos de JavaScript ajustados a la zona horaria institucional (America/Caracas).

2.3 Caso 3: Fallo en la Ruta Estática de Archivos para Multer en Producción

• El Error de la IA: Al implementar la subida de imágenes locales mediante Multer en NestJS, el agente de IA propuso una ruta de guardado fija y dependiente del sistema de desarrollo (ej. E:/SISTEMAS DE INFORMACIÓN/.../uploads). Esto provocaba un colapso en la VPS Linux, ya que la ruta física no existía, impidiendo que los organizadores guardaran eventos con imágenes.
• Detección y Corrección: El desarrollador identificó el error al observar la pila de excepciones de PM2 (pm2 logs facyt-events-backend) en la VPS. Se solucionó configurando una ruta de resolución dinámica basada en el directorio del proceso (path.join(process.cwd(), 'uploads')), y garantizando que la carpeta uploads fuera mapeada y creada correctamente por el script de despliegue.

2.4 Caso 4: Bloqueo de Hilos por Envío Sincrónico de Correos de Notificación

• El Error de la IA: En la primera versión del sistema de inscripciones, la IA propuso un flujo lineal y síncrono para el envío de correos electrónicos. El endpoint del backend abría la conexión con el servidor SMTP, cargaba el template HTML, compilaba la imagen del código QR y enviaba el correo antes de retornar una respuesta HTTP exitosa al cliente.
• El Impacto en Producción: Cuando múltiples usuarios intentaban registrarse simultáneamente, el hilo único de ejecución de Node.js se bloqueaba en la VPS esperando la latencia externa del servidor de correo de Google (que tardaba entre 2 y 5 segundos por petición). Esto disparó tiempos de respuesta inaceptables en el frontend, cancelaciones de peticiones por timeout y caídas temporales del backend.
• Detección y Corrección: El desarrollador identificó este cuello de botella analizando los reportes de rendimiento y los picos de uso de CPU de PM2 en la VPS. La solución consistió en implementar un desacoplamiento asíncrono y no bloqueante de la responsabilidad de envío de correo utilizando el módulo de eventos nativo de NestJS (@nestjs/event-emitter):
* Al inscribirse el usuario, el servicio de base de datos guarda la tupla en PostgreSQL en milisegundos y dispara un evento interno: this.eventEmitter.emit('registration.completed', data).
* Inmediatamente se responde un HTTP 201 Created al navegador de Next.js, liberando al usuario.
* Un listener asíncrono en background (@OnEvent('registration.completed')) captura el evento de forma independiente, compilando y despachando el correo en segundo plano sin interrumpir los recursos principales del servidor.

2.5 Caso 5: Bucle Infinito de Lectura del Lector QR Continuo

• El Error de la IA: Al diseñar el escáner QR continuo, la IA recomendó que al leer exitosamente un código QR se reactivara el escaneo de forma inmediata tras cerrar el modal. El código original carecía de un período de gracia o memoria de lectura.
• El Impacto en Producción: Cuando el moderador escaneaba un QR y posteriormente cerraba el modal o confirmaba la asistencia, la cámara (que seguía apuntando físicamente a la pantalla del dispositivo del participante) leía instantáneamente el mismo código QR en el siguiente frame. Esto provocaba que el modal de *"Registro Ya Procesado"* se abriera en un bucle infinito del que el moderador no podía salir.
• Detección y Corrección: El desarrollador detectó este comportamiento durante las pruebas físicas de aceptación en dispositivos móviles. Para solucionarlo, implementó una ventana de cooldown (tiempo de enfriamiento) de 4 segundos controlada mediante referencias en el hook del escáner:
* Se guardan en variables de estado local (lastScannedValue y lastScannedTime) el valor y la hora del último código QR leído.
* Si el detector lee el mismo código dentro del rango de 4 segundos, la instrucción se ignora y el hilo del renderizador de la cámara continúa de manera limpia.
* Si se lee un código QR diferente (un nuevo participante), el sistema lo procesa de manera inmediata sin latencia, garantizando un flujo ininterrumpido en el punto de acceso físico del evento.

2.6 Caso 6: Alucinación en la Validación de Capacidad de Aforo

• El Error de la IA: Al solicitar validación para evitar que el aforo estimado de una solicitud superara la capacidad total del espacio físico, el agente de IA generó un validador en el DTO que impedía el submit del formulario mediante un error HTTP de tipo bloqueante.
• Detección y Corrección: El desarrollador identificó que un bloqueo estricto afectaba negativamente la experiencia de usuario y la flexibilidad administrativa (ya que los profesores organizadores a veces estiman un aforo superior previendo inasistencias o habilitando sillas adicionales). La solución consistió en revertir el bloqueo estricto en el backend y mover la regla al frontend, diseñando una advertencia blanda interactiva:
* Se utiliza el contexto de confirmación asíncrono (useConfirm) en lugar de diálogos nativos del navegador.
* Si el aforo es mayor a la capacidad, se advierte de forma explícita al usuario del sobre-aforo, permitiéndole confirmar si desea continuar o cancelar para reajustar los números, respetando la libertad de diseño del docente.

3. Consideraciones Éticas y Privacidad de Datos

El diseño de FaCyT Events incorpora la reflexión ética como un pilar fundamental de la arquitectura de la información, protegiendo los derechos de los miembros de la comunidad universitaria:

3.1 Garantía de Privacidad de Datos Personales Sensibles

El sistema procesa información de identificación personal sensible (Nombres, Cédulas de Identidad, Correos Electrónicos y Roles organizacionales). Para evitar la exposición o el uso indebido de esta información, se implementan las siguientes capas de seguridad:

• Cifrado de Credenciales: Todas las contraseñas de los usuarios con acceso al sistema (Coordinadores, Moderadores, Organizadores) se someten a un algoritmo de hash criptográfico de alta entropía (bcrypt con 12 rondas de sal) antes de ingresar a la base de datos, garantizando que ni los administradores del servidor puedan visualizarlas en texto plano.
• Seguridad en Perfil: Para robustecer la autogestión de perfil, la plataforma incorpora validación doble de contraseñas y visibilidad interactiva con iconos de ojo (Eye/EyeOff), previniendo errores de tipeo accidentales por parte del docente.
• Principio de Minimización de Datos: En el módulo de registro, los datos recopilados de participantes anónimos (invitados) se guardan estrictamente con el propósito operativo de controlar el aforo, generar el token QR único y despachar el certificado por correo electrónico. Estos datos están aislados y nunca se exponen en endpoints de la API pública.

3.2 Responsabilidad Ética de la Comunicación y Prevención del Spam

En entornos institucionales, el correo electrónico es una herramienta de trabajo formal susceptible de verse saturada por comunicaciones innecesarias. El sistema de correos de FaCyT Events se rige por un código ético estricto:

• Exclusión de Fines Promocionales: La plataforma tiene prohibido el envío de boletines o correos masivos que no correspondan a una interacción explícita y consentida del usuario.
• Filtro de Triggers Críticos Organizacionales: Los correos informativos automáticos se limitan única y exclusivamente a notificaciones de carácter operativo y logístico:
* *Envío del QR de Acceso:* Alivio al estudiante para asegurar su derecho de entrada in situ.
* *Reprogramación o Cancelación:* Respeto absoluto del tiempo del estudiante y docente de la facultad, notificándoles de forma reactiva en copia oculta (BCC) si el evento académico sufrió una alteración o suspensión por causas de fuerza mayor.
* *Aprobación/Rechazo de Solicitudes:* Transparencia y fluidez del proceso administrativo del Decanato hacia los profesores organizadores (incluyendo las justificaciones de rechazo para permitir correcciones inmediatas).

3.3 El Límite de la Automatización frente al Control Humano

Un principio ético clave en el diseño de sistemas de información es que el software debe servir de apoyo a la toma de decisiones, pero nunca suplantar la gobernanza ni la responsabilidad humana.

• El Factor Humano sobre el Algoritmo (Límite de la Automatización): Aunque el backend previene automáticamente las colisiones horas-espacios para evitar incidentes logísticos cotidianos en la facultad, existen situaciones institucionales de fuerza mayor (emergencias nacionales, consejos rectorales imprevistos, asambleas de decanato) que demandan la anulación manual del algoritmo. Un sistema de información inmutable que impidiera resolver estas contingencias sería inútil para la administración universitaria real.
• Implementación: El sistema delega la decisión final de anulación de forma exclusiva al rol de Coordinador. Si el Decanato necesita reservar de emergencia un espacio físico pese a existir un taller agendado previamente, el Coordinador (humano), tras deliberar y reasignar las prioridades institucionales, puede anular administrativamente el bloqueo temporal del software, notificando asíncronamente por correo a los participantes afectados y reprogramando el evento en conflicto, respetando la estructura de gobernanza y la soberanía del Decanato.

4. Limitaciones Actuales y Plan de Escalabilidad (Mejoras Futuras)

En concordancia con el principio de control y honestidad técnica de la asignación, se declaran los límites actuales de la versión estable y su ruta de crecimiento modular:

4.1 Limitaciones del Sistema (Versión 1.4.0)

• Dependencia de Red in situ: El escaneo de códigos QR mediante smartphones por parte del Moderador requiere una conexión de datos móvil estable o acceso a la red WiFi institucional en el punto de acceso del auditorio o laboratorio para validar el token asíncronamente contra la API de NestJS en tiempo real.
• Restricción de Almacenamiento VPS: La subida de imágenes de portadas y galerías para evidencias del historial de eventos se almacena físicamente en la VPS del desarrollador, lo que impone un límite de espacio que requiere mantenimiento de depuración periódico por parte del administrador para evitar colapsos del servidor.

4.2 Plan de Escalabilidad (Mejoras Futuras)

• Módulo de Pagos Flexibles (`PaymentsModule`): Habilitar la pasarela de pagos integrada cuyos campos de base de datos (is_paid y price) ya se encuentran estructurados de forma nativa en la tabla de eventos para eventos de extensión autofinanciados.
• Sincronización en Tiempo Real mediante WebSockets: Integrar tecnología de WebSockets en NestJS para notificar de forma reactiva e instantánea a las pantallas de los estudiantes inscritos si un evento cambia de estado, se cancela o se reprograma de última hora.
• Módulo de Reportes Avanzados: Automatizar la exportación de análisis estadísticos avanzados de uso de los espacios de la facultad directamente al buzón del Decanato para optimizar los presupuestos de mantenimiento.

5. Declaración Formal de Propiedad Intelectual y Autoría

• Responsable y Propietario Único del Proyecto: Guillermo Cedeño.
• Declaración de Autoría: Se hace constar que el diseño conceptual, el análisis sistémico de procesos, el diseño del esquema de datos relacional y su normalización, la configuración e implementación física del servidor VPS, el despliegue con PM2, HTTPS y Nginx, y la validación de todas las pruebas funcionales pertenecen en su totalidad al autor del proyecto. Las herramientas de Inteligencia Artificial (agentes de Antigravity) se utilizaron exclusivamente como copilotos de asistencia sintáctica y aceleración tecnológica, asumiendo el desarrollador la responsabilidad técnica absoluta sobre la totalidad del código fuente de FaCyT Events.