I AM J AI SAFETY FRAMEWORK

1. Scope and Safety Objectives

The Framework applies to AI features developed, configured, integrated, deployed, or materially operated by I am J.

• Prevent or reduce foreseeable physical, psychological, informational, economic, legal, security, and societal harm.
• Preserve human control over consequential actions.
• Detect and respond to unsafe behavior, misuse, and changing risk.
• Support reliable operation in real-world and resource-constrained environments.

2. Governance and Roles

Each material system or deployment should have a designated business or product owner and identified contributors for engineering, security, privacy, legal or compliance, and responsible AI review as appropriate.

• Owners are responsible for maintaining the use definition, risk record, approval status, operational controls, monitoring, and corrective actions.
• Material safety concerns may be escalated to executive leadership and may stop or restrict a release or deployment.

3. Risk Classification

Risk classification considers the severity and likelihood of harm, the number and vulnerability of affected people, system autonomy, access to tools or external systems, data sensitivity, exposure to misuse, reversibility, and reliance on AI output.

• Lower-risk systems may use standard controls and routine review.
• Elevated-risk systems require documented evaluation, additional safeguards, and explicit approval.
• High-impact, life-critical, rights-affecting, or otherwise unacceptable uses may be prohibited, delayed, or limited to supervised research.

4. Safety-by-Design Controls

Safety requirements should be incorporated before implementation.

• Constrain the intended scope and permissions.
• Use safe defaults, confirmation steps, rate limits, and least-privilege access.
• Separate informational assistance from authority to act.
• Provide interruption, fallback, and recovery mechanisms.
• Design interfaces that communicate uncertainty and do not encourage blind reliance.

5. Data and Model Risk Controls

Model and data choices are reviewed for suitability, provenance, privacy, security, representativeness, limitations, and known risk.

• Use models appropriate to the sensitivity and consequence of the task.
• Protect system prompts, credentials, user information, and proprietary data.
• Limit training, retention, or reuse of data according to lawful purpose and policy.
• Assess dependence on third-party models and services, including outage, policy, and version-change risks.

6. Pre-Deployment Evaluation

Evaluation plans are proportionate to risk and may include:

• Functional and task-performance testing.
• Safety-policy and prohibited-content testing.
• Hallucination, uncertainty, and factuality evaluation.
• Bias, fairness, multilingual, cultural, and accessibility testing.
• Prompt-injection, jailbreak, tool-abuse, and data-exfiltration testing.
• Privacy and security review.
• Load, resilience, connectivity, failover, and degraded-mode testing.
• Human-factors and operational-readiness review.

7. Release Readiness and Approval

Before release or material deployment, responsible owners should confirm that:

• The intended use and boundaries are documented.
• Required tests have been completed and material findings addressed or accepted by authorized owners.
• User disclosures and operating guidance are available.
• Monitoring, incident response, rollback, and support arrangements are in place.
• Contractual and deployment-specific responsibilities are defined.

8. Deployment Safeguards

Controls may include identity and access management, configuration restrictions, content and action safeguards, human confirmation, logging, rate limits, geographic or customer restrictions, network controls, and administrator settings.

J-SPARK Nexus and other field deployments additionally consider device custody, local administration, physical security, connectivity interruptions, power conditions, user training, safeguarding, maintenance, and responsible withdrawal.

9. Monitoring and Detection

Monitoring is designed to detect material changes in performance, misuse, unsafe outputs, adversarial activity, security incidents, user complaints, and environmental or operational changes.

• Monitoring should be risk-based and privacy-conscious.
• Metrics and thresholds should be periodically reviewed.
• Signals may include automated testing, sampled review, support cases, customer reports, security telemetry, and field feedback.

10. Incident Response

Potential AI safety incidents are triaged according to severity, scope, urgency, and ongoing exposure.

• Immediate actions may include limiting features, disabling integrations, isolating a deployment, revoking credentials, notifying administrators, preserving relevant evidence, or rolling back changes.
• Investigation should identify affected users, root causes, control failures, and corrective actions.
• Material incidents may require notification to customers, partners, regulators, or affected people in accordance with law and contract.

11. Change Management and Re-Evaluation

Material changes to models, prompts, tools, data sources, user populations, integrations, permissions, autonomy, or operating environments can change risk and require re-evaluation.

• Third-party model upgrades are not assumed to be risk-neutral.
• Emergency changes should receive retrospective review.
• Older configurations should be retired or restricted when they cannot meet current safety requirements.

12. Red Teaming and Independent Challenge

I am J supports structured challenge of assumptions and controls through internal testing, external expertise, research collaboration, customer feedback, and independent review where proportionate and feasible.

Testing is conducted lawfully and with safeguards to avoid creating unnecessary risk or publishing operational details that could enable abuse.

13. Special Controls for High-Impact Contexts

Medical, emergency, education, employment, financial, legal, public-sector, critical-infrastructure, and vulnerable-population uses require heightened review and cannot rely on AI as the sole authority for consequential decisions.

• Qualified human judgment and lawful process must remain available.
• Performance claims must be validated for the specific context.
• Appropriate records, appeal or correction mechanisms, and deployment accountability are required.

14. Continuous Improvement

Lessons from testing, incidents, research, law, standards, customers, and affected communities are used to improve requirements and controls.

This Framework will evolve as I am J’s capabilities and deployments mature. Publication of this Framework does not imply that every possible risk has been identified or eliminated.

15. Contact and Governance Questions

Questions, concerns, research inquiries, partnership proposals, or reports related to this document may be submitted through the I am J contact page.