Safety Norms: Deep Learning Applications

1Purpose, Scope, and Safety Principles

These norms set minimum expectations for anyone who collects data for, trains, evaluates, deploys, or operates deep learning models in a course, laboratory, or applied project. Deep learning here means systems built from multi-layer neural networks, including image classifiers, language models, speech recognition, recommendation engines, and forecasting tools. The norms cover the full lifecycle from dataset collection through retirement of a model.

Three principles guide every rule. First, people come before performance: a model that harms users, leaks personal data, or fails silently is a failed system regardless of its accuracy score. Second, access is granted by documented need and authorization, not convenience. Third, every shortcut that bypasses review must be recorded and reversible. In this document, MUST marks a mandatory rule set by the institution or project, and SHOULD marks a recommended practice that may be adapted only with documented justification.

2Roles, Competence, and Accountability

A named owner must be assigned to every model, dataset, and compute environment. The owner approves the intended use, the data sources, and the release decision. Other roles include data stewards who confirm lawful collection and consent basis, engineers who build and test pipelines, reviewers who check fairness and safety findings, security staff who manage credentials and network boundaries, and a supervisor who approves production changes.

Competence is demonstrated through role-based training and supervised practice, not self-declaration. Accountability is recorded in the project file so that every decision can be traced to a person.

• The project owner MUST record the intended purpose, prohibited uses, and affected users before training begins.
• Data stewards MUST confirm that each dataset has documented provenance and a lawful basis for use, and they MUST flag personal or sensitive attributes.
• Engineers MUST complete required training on data handling and secure development before receiving write access to production systems.
• Anyone without authorization MUST NOT run models against live customer data, connect to restricted services, or probe systems they do not own.

3Realistic Hazards and Risk Assessment

Deep learning hazards fall into several groups. Privacy hazards include memorization of training records, membership inference, and accidental exposure of personal information in outputs or logs. Security hazards include leaked API keys, poisoned training data, tampered model files from untrusted sources, and prompt injection against language model tools. Safety hazards arise when outputs drive physical or clinical decisions, such as industrial control, vehicles, or triage, where errors can injure people. Reliability hazards include distribution shift, silent accuracy decay, and brittle behavior on rare inputs. Operational hazards include runaway compute costs, accelerator overheating, and unsafe handling of high-power workstations.

Each project MUST complete a written risk assessment before training on new data or deploying a model. Rate each hazard by likelihood and severity on a three-level scale of low, medium, and high. Any high rating requires a documented mitigation, a named approver, and a review date. Any use that could affect health, safety, legal rights, employment, credit, housing, or access to essential services is treated as high risk by default and requires formal ethical and legal review, the scope of which varies by jurisdiction.

• Example: a face-matching prototype trained on scraped images is high risk for privacy and must not proceed without legal and ethics review.
• Example: a product recommender retrained weekly on unfiltered clickstream data is medium risk for drift and requires defined monitoring thresholds.
• Example: a lab workstation with several high-wattage accelerators is a medium physical risk that requires electrical inspection by qualified facilities staff.

4Preventive Controls and Safe Practices

Preventive controls reduce the chance that a hazard becomes harm. Data controls come first. Training data MUST be limited to what the stated purpose requires, de-identified where feasible, and stored in approved repositories. Direct identifiers must be removed or masked before any sharing. Evaluation data must be held out strictly, and test records must never leak into training. Keep a versioned data manifest so every model can be traced to its inputs.

Model controls focus on validation before release. Evaluate performance across subgroups and edge cases, not only average accuracy. Test robustness to noisy, shifted, and adversarial inputs at a level proportionate to the risk. For generative systems, test for harmful, private, or unsupported outputs and document refusal behavior. A model MUST NOT move to production without an approved evaluation report, a tested rollback plan, and a named monitoring owner.

• Version code, configuration, data manifests, and model artifacts together, and record a cryptographic hash for each model file before transfer.
• Load pretrained weights only from sources the organization has vetted. Some serialized model formats can execute code when loaded, so prefer safe formats and load files only in isolated environments.
• Run experiments in sandboxed environments with resource quotas so runaway jobs cannot exhaust shared clusters or budgets.
• Keep a human in the loop for decisions with significant consequences, and document how a reviewer can override or stop the system.
• Do not deploy a model for a purpose different from the approved one without repeating the risk assessment.
• Authorized red-team or adversarial testing MUST be written, scoped, time-bounded, and approved by the system owner and security team before any probing begins.

5Data, Privacy, Security, and Operational Safeguards

Access control follows least privilege. Use individual accounts, multi-factor authentication, and role-based permissions for datasets, notebooks, training clusters, and model registries. Credentials MUST NOT be embedded in notebooks, code repositories, or shared documents. Rotate secrets on a defined schedule and revoke access promptly when a person changes roles or leaves. Access and download logs must be retained according to the retention schedule approved by the institution.

Privacy safeguards apply throughout the lifecycle. Conduct a privacy impact review before using personal data. Prefer aggregation, validated privacy-preserving techniques where appropriate, and on-premises processing for sensitive datasets. Do not send restricted data to third-party model services unless a contract, data processing agreement, and approval are in place. Treat model outputs as potentially containing fragments of training data and screen them before publication. Rules on personal, biometric, and automated decision data vary by jurisdiction and must be verified with a qualified privacy professional.

• Equivalent safeguards for workstations: lock sessions when unattended, use full disk encryption, and keep sensitive exports off removable media unless approved.
• Power and cooling for accelerators and racks must be installed and inspected by qualified electrical and facilities staff. Users MUST NOT open power supplies, bypass thermal shutdowns, or stack equipment that blocks airflow.
• Maintain ventilation and temperature monitoring in server rooms, and keep liquids away from accelerators and cabling.
• Annotators reviewing harmful or disturbing content must receive handling guidance, access to support resources, and scheduled breaks.
• Maintain backups of critical artifacts, test restoration steps periodically, and document a fallback procedure for when a model is unavailable.

6Incident Response, Escalation, and Emergencies

Any suspected security breach, privacy exposure, harmful output, safety-related failure, or serious malfunction is an incident. Report it immediately to the system owner and the designated security or privacy contact, without waiting to confirm the cause. Near misses, such as a model that nearly disclosed a record or a dataset copied to the wrong location, MUST also be reported because they reveal weaknesses in controls.

For immediate danger to people, contact local emergency services and follow building procedures. Smoke, a burning smell, or electrical fault near equipment requires isolation of power by trained staff and evacuation under building rules. Do not use water on energized electrical equipment. For model incidents, first contain the problem: disable the endpoint, revoke exposed keys, quarantine affected datasets, and preserve logs. Do not delete evidence. Escalate to legal, privacy, and communications contacts when personal data or external users are affected. Notification duties depend on jurisdiction and contract, so verify them with counsel.

• Within the organization's defined reporting window, complete an incident record with timeline, affected systems, data categories, and containment steps.
• Run a blameless review and record corrective actions with named owners and due dates.
• Keep an approved rollback model ready so a previous safe version can replace a failing one quickly.

7Records, Training, Monitoring, and Review

Records prove that norms are followed and allow errors to be traced. Maintain model documentation describing purpose, training data sources, evaluation results, known limitations, and the monitoring plan. Keep approvals, risk assessments, access reviews, and incident records in a controlled repository. Retention periods are set by institutional policy and applicable law.

Training is required before access and should be refreshed at a defined interval. Cover data protection, secure coding, responsible use, and the escalation path. Monitoring continues after release: track input drift, output error rates, subgroup performance, latency, cost, and user complaints against thresholds set in the risk assessment. Review these norms at each project phase and after any serious incident, significant system change, or new applicable requirement.

• Conduct access reviews at a defined interval and remove dormant accounts.
• Retrain or retire a model when monitoring thresholds are breached, and document the decision and its approver.
• Use these norms as a baseline. Adapt them through approved local procedures, and where a norm conflicts with law or vendor safety instructions, follow the stricter requirement and seek qualified advice.

Implementation checklist

• Confirm the named owner, intended use, and prohibited uses are recorded before training.
• Verify dataset provenance, lawful basis, and approval for any personal data handling.
• Complete the written risk assessment and rate every hazard as low, medium, or high.
• Store credentials in an approved secrets manager, never in code, notebooks, or shared documents.
• Evaluate performance across subgroups and edge cases before any release decision.
• Load only vetted model files, and only in isolated environments.
• Obtain written approval before any red-team or adversarial testing begins.
• Confirm a tested rollback plan, a monitoring owner, and alert thresholds exist.
• Report incidents and near misses immediately and preserve logs without deleting evidence.
• Review access rights and these norms on the defined schedule and after major changes.