AI engineering, safety, and research

Status: Cross-cutting track. Apply these practices from the first project, not only at the end.

Learning objectives

• make a project reproducible for another student;
• test data, code, model behavior, and failure paths;
• identify privacy, security, fairness, and physical safety risks; and
• communicate evidence, uncertainty, limitations, and rollback plans.

Ordered subtopics

1. Reproducible environments and dependency management
2. Testing data, models, and applications
3. APIs, containers, and deployment
4. Monitoring drift, latency, and failures
5. Model cards, data cards, and documentation
6. Privacy, consent, fairness, and accessibility
7. Security, threat modeling, and misuse prevention
8. Robot safety and human oversight
9. Reading papers and reproducing experiments
10. Presenting results and building a portfolio

Every project will include its purpose, data sources, limitations, evaluation, safety notes, and next steps.

Lessons learned to carry forward

• A working demo is not the same as a reliable system.
• A high metric can hide leakage, imbalance, or a mismatch with the real goal.
• A model cannot grant itself permission to access data or control hardware.
• Documentation is part of the engineering, not decoration added after the demo.
• When uncertainty is high, reduce scope and ask for human review.

References

• Learning and project practices
• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications

Minimum release checklist

• Reproducible setup instructions
• No secrets in code, notebooks, logs, or screenshots
• Normal, edge, and failure tests
• Human review for consequential outputs
• Privacy and consent boundary
• Known limitations and out-of-scope uses
• A rollback or safe-stop plan for deployed systems