Date: July 21, 2026
Document status. This is a proposed policy framework. “Will,” “must,” and “shall” describe the controls Reka commits to operating when this policy was approved; they do not by themselves represent a certification or claim that every control is already implemented. Deployment-specific evidence, test results, owners, and contractual terms must be completed before production approval.
Executive statement
Reka develops small, efficient multimodal models optimized for visual understanding.
We believe these systems can help people understand and work with visual information across many fields, including media, entertainment, sports, enterprise operations, and physical security. Potential applications include organizing and searching video, analyzing events, supporting content workflows, generating structured metadata, and helping trained people focus on relevant moments. Whatever the sector, Reka technology must respect privacy, intellectual property, human agency, equal treatment, and the context in which it is used.
In that context, Reka can help identify observable events, such as “a person crossed over a turnstile barrier,” for review by an authorized professional. It is not an oracle, a determination of intent, or a substitute for trained judgment, due process, or established emergency and security procedures. Other sectors require controls tailored to their own risks, such as rights and provenance in media, athlete and audience privacy in sports, and appropriate disclosure for generated or transformed content.
Reka commits to five foundations:
Benefit people and the public. A deployment must have a legitimate, documented purpose and a reasonable expectation of public benefit that outweighs its risks.
Keep humans responsible. The model may surface evidence and support review; accountable people make consequential decisions.
Protect privacy, dignity, and equal treatment. We minimize data, reject identity-based surveillance, and test for disparate failures and harmful proxies.
Match safeguards to risk. Higher-risk capabilities and uses require stronger evaluation, approval, monitoring, access controls, and evidence. Some uses are prohibited regardless of safeguards.
Give customers meaningful control over deployment and data. Customers can choose customer-controlled and on-premises deployments where supported, keeping their data and AI serving environment within infrastructure they govern.
1. Purpose and scope
This framework establishes Reka’s principles, prohibited uses, governance structure, and lifecycle controls for identifying, assessing, mitigating, accepting, monitoring, and communicating AI risk. It is designed to address:
model and algorithm risk;
data quality, lineage, privacy, and security;
equity, bias, and accessibility;
operational resilience and vendor risk;
ethical, societal, legal, and reputational impact; and
model change, obsolescence, incident response, and continuous improvement.
It applies across sectors and use cases, including media, entertainment, sports, enterprise, and physical security. It covers general-purpose and specialized visual-language models; supporting data pipelines, prompts, classifiers, user interfaces, and integrations; and customer-specific configurations. A risk assessment covers the whole deployed system, not only the underlying model. Source content, data rights, capture devices, image quality, prompt language, thresholds, operator workflow, downstream action, retention, audience, and social context can be as important as model weights.
When contracts, law, or customer policies impose stricter requirements, the stricter requirement controls. When a deployment cannot meet this framework, Reka will not approve it or will suspend it until the risk is resolved.
2. Core principles
2.1 Public benefit and avoidance of harm
Reka technology should work for people who use and pass through the environments in which it operates. We assess expected benefits alongside risks to physical safety, civil rights, privacy, equal treatment, autonomy, access to public services, and public trust. Commercial value does not override unacceptable harm.
2.2 Purpose limitation and proportionality
Every deployment must state a specific operational purpose, the event to be detected, who may act on an alert, and what action may follow. Data and capabilities may not be repurposed for a materially different goal without a new review. The intrusiveness, coverage, retention, and consequence of a system must be proportionate to the documented need, and a less intrusive effective alternative should be preferred.
2.3 Context-appropriate and evidence-based use
Reka models accept open-ended natural-language instructions, and the ethical meaning of a phrase depends on its context and consequence. A search for “a suspicious person” may be a low-consequence creative or media-retrieval task, while using the same phrase to trigger intervention against a real person can create serious bias and civil-rights risk. Reka does not claim to inspect or technically block every prompt, particularly in customer-operated environments.
For uses that can materially affect a person’s rights, safety, access, reputation, or treatment, customers should define alerts and decision criteria in terms of observable events, objects, or conditions and validate them for harmful proxies. Subjective model outputs must be treated as search hypotheses or leads, not findings of identity, intent, criminality, or dangerousness. Protected traits and contextual proxies such as culturally associated clothing, disability, or perceived socioeconomic status must not be used as the reason for an adverse action.
Reka supports this principle through documentation, examples, deployment scoping, customer-configurable controls where available, and contractual use restrictions for higher-risk deployments. Customers remain responsible for prompt governance and downstream decisions within the systems they operate.
2.4 Human agency and accountable oversight
Models may recommend where a human should look; they do not determine guilt, intent, identity, or legal status. For alerts that could lead to contact, denial of service, enforcement, detention, or another significant consequence, an authorized and trained human must review the underlying evidence and relevant context before acting, except where established emergency procedures require immediate action to protect life.
Even in an emergency, an AI output alone may not authorize force.
2.5 Privacy and security by design
Reka will minimize collection, processing, access, retention, and disclosure; protect data in transit and at rest; separate customer environments where appropriate; and design for deletion, logging, and least-privilege access. Customer video will not be used to train or improve general Reka models without explicit written authorization and an approved data-governance review.
2.6 Fairness and inclusion
Fairness is a continuing engineering and governance obligation, not a one-time benchmark. We assess whether errors or downstream consequences are distributed inequitably across people, locations, environmental conditions, or legally and ethically relevant groups. We use controlled evaluation, stakeholder feedback, and production monitoring to detect and mitigate harmful disparities.
2.7 Transparency, contestability, and honesty about limitations
Reka will document intended uses, known limitations, evaluation methods, model and configuration versions, important changes, and the meaning of outputs. Users should see enough information to review an alert rather than treating it as a conclusion. Reka and the deploying organization should provide appropriate channels for questions, complaints, and correction.
2.8 Reliability, resilience, and continuous improvement
We design for foreseeable edge cases, monitor performance and drift, test recovery and rollback, and reevaluate when models, data, prompts, cameras, operating conditions, or downstream uses change. A successful predeployment test is not a permanent assurance.
2.9 Customer control, deployment choice, and data sovereignty
Reka views customer control as a core design principle. Our models can make customer-operated deployment practical, including on-premises, private-cloud, edge, or other customer-controlled environments where the relevant product and license support it. This gives customers the option to keep source data, prompts, outputs, model-serving infrastructure, encryption keys, logs, and retention controls within systems they govern.
On-premises deployment is a privacy- and sovereignty-enhancing option, not an automatic guarantee of safety or compliance. Reka and the customer must document the division of responsibility for infrastructure security, access control, patching, monitoring, backups, incident response, model and configuration updates, deletion, and audit evidence. The same prohibited-use, evaluation, fairness, human-oversight, and lifecycle requirements apply regardless of where a model is hosted.
3. Non-negotiable prohibitions
Reka will not knowingly build, enable, sell, configure, or support its technology for the following uses:
These are use- and outcome-based boundaries, not a representation that Reka can technically prevent every prohibited prompt or combination of systems. This is particularly important for on-premises and customer-operated deployments, where Reka may not receive or inspect prompts, outputs, or logs. Reka applies these boundaries through product and sales diligence proportionate to risk, contracts, documentation, limits on Reka-provided configuration and support, investigation of credible misuse reports, and suspension or termination where Reka has the contractual and technical ability to act.
3.1 Facial recognition and biometric identity
facial identification or verification;
one-to-one or one-to-many face matching;
face embeddings or templates used to recognize a person;
face-based watchlists;
inferring or confirming identity from facial images; or
re-identifying a person across time or cameras by combining facial or biometric signals.
Incidental processing of faces present in ordinary video does not authorize face recognition. Where technically and operationally feasible, deployments should support masking, redaction, cropping, or other minimization for people not relevant to a reviewed incident.
3.2 Weapons and actions intended to harm human life
Reka technology may not be used to aim or fire a weapon; provide autonomous or semi-autonomous weapons targeting; or make decisions whose intended purpose is to injure or kill a person. It may not be integrated as a targeting component even if a human nominally remains “in the loop.”
This prohibition does not prevent narrowly scoped, separately reviewed uses whose purpose is to protect life, such as detecting smoke, a person on train tracks, or an abandoned hazardous object, provided the system is not used to target people and satisfies this framework.
3.3 Discriminatory profiling and consequential sensitive-trait inference
Reka will not knowingly support deployments that use actual or inferred race, ethnicity, nationality, religion, sex, gender identity, sexual orientation, disability, health status, immigration status, political affiliation, or other protected or highly sensitive traits to discriminate, impose an adverse consequence, or create an unlawful person-level profile. Clothing, language, location, companions, or other contextual signals must not be used to evade this boundary through proxies.
This boundary does not prohibit every reference to a human attribute in a legitimate low-consequence context, such as organizing licensed media or analyzing an authorized sports dataset. Such uses still require a lawful purpose, appropriate data rights, accuracy proportional to the consequence, and controls against harmful repurposing. Controlled fairness testing may use responsibly sourced sensitive attributes when lawful, necessary, access-restricted, and approved solely to evaluate and reduce disparities; those attributes must not become operational decision features without a separate justified review.
3.4 Discriminatory person-level risk scoring and automated consequential profiling
Reka will not knowingly support deployments whose material purpose is social scoring, predictive policing, or assigning a real person a criminality or dangerousness score based on protected traits, appearance, associations, generalized historical enforcement data, or unvalidated behavioral proxies. A subjective label generated during search or analysis must not be represented as a factual determination or used as the sole basis for enforcement, denial of an essential service, or another significant adverse action.
This boundary does not require blanket filtering of individual words or ordinary creative and analytical queries. It focuses on the deployment’s intended function, the data and proxies used, and the consequence of the output. For customer-operated deployments, the customer is responsible for preventing prohibited downstream uses; Reka may decline configuration assistance, support, or continued licensing when it becomes aware of a material violation.
3.5 Emotion, honesty, or intent claims in consequential settings
Reka will not market model outputs as reliable determinations of a real person’s emotions, truthfulness, mental state, aggressiveness, or intent from face, body, voice, or mannerisms, or knowingly support their use as the sole basis for a consequential decision. Models may describe observable actions or generate subjective interpretations for creative and analytical purposes, but those interpretations must not be presented as verified psychological facts.
3.6 Sole-source consequential decisions
An AI alert or summary may not be the sole basis for arrest, detention, use of force, citation, denial of transportation or public service, employment action, housing action, credit decision, insurance decision, or other legal or similarly significant consequence.
3.7 Unlawful, covert, or indiscriminate surveillance
Reka will not support surveillance that lacks lawful authority, a defined purpose, appropriate notice or governance, or proportionate limits. Covert deployment, persistent person tracking, or expansion beyond the approved area and purpose requires a new review and will be rejected where inconsistent with this framework.
3.8 Circumvention
Customers and partners may not circumvent safeguards, conceal the real use case, combine Reka outputs with another system to perform a prohibited use, or ask Reka to custom-build a nominally different capability that has the same prohibited effect. Reka may suspend access, decline support, or terminate a deployment for a material violation.
4. Physical-security deployment standard
This section defines the minimum controls for camera-based alerting and investigation in public or semi-public environments, including transit.
4.1 Use-case specification
Before any pilot, the deployment owner must complete a use-case record containing:
the public or operational benefit sought;
a concrete description of the observable event;
locations, cameras, operating hours, and population affected;
authorized users and downstream recipients;
expected operator action and prohibited actions;
plausible false-positive and false-negative harms;
privacy, equity, accessibility, security, and civil-rights risks;
alternative, less intrusive methods considered;
performance and fairness acceptance criteria;
retention and deletion rules;
notice, complaint, and escalation mechanisms; and
a named Reka owner and customer owner.
4.2 Prompt and alert design guidance
High-impact workflows and objective and testable prompts generally produce outputs that are easier to validate, explain, and audit. Reka recommends defining the event, time interval, and relevant zone or object rather than asking the model to infer a person’s character or intent.
More testable examples:
“A person crossed over or under the turnstile barrier.”
“A person entered the track area from the platform.”
“Smoke or visible flame is present in the defined camera zone.”
“An object has remained unattended in the defined zone for more than the configured duration.”
Examples requiring greater caution and customer-defined review:
“Suspicious activity.”
“A dangerous-looking person.”
“Possible fare evader” without an observable definition of the event.
“Person behaving abnormally” without a defined operational meaning.
Reka does not maintain a universal banned-word list and does not undertake to review every customer prompt. Customers own their prompt libraries, authorized-user policies, and downstream response procedures. Where Reka directly assists with a high-impact configuration, Reka will recommend objective alternatives, document material limitations, and avoid representing subjective outputs as determinations of intent or wrongdoing. Reka may provide optional configuration, logging, or moderation controls where supported, but their availability and allocation of responsibility must be documented for the deployment.
4.3 Human review and response
The interface should present the relevant clip or frames, time, camera, configured event definition, model/configuration version, and uncertainty or confidence information where reliable. Operators must be trained to:
treat an alert as a lead, not a finding;
inspect the underlying video and surrounding context;
disregard alerts unsupported by the evidence;
avoid inferring identity, intent, or protected traits;
follow existing response, escalation, and documentation procedures; and
report harmful, biased, or recurring errors.
For enforcement-adjacent uses, Reka and the customer must document the minimum independent evidence required before action. Automated bulk enforcement is not permitted.
4.4 Pilot before production
High-risk deployments must begin in offline evaluation or shadow mode, where outputs do not trigger action. The pilot must represent expected cameras, lighting, crowding, weather, occlusion, station layouts, accessibility devices, clothing variation, and operating conditions. Production approval requires documented results, residual-risk acceptance, trained users, monitoring, rollback, and incident procedures.
4.5 Investigation controls
Customers should govern natural-language search of archived video by authorized purpose, role, date/time, location, and retention policy, with logging appropriate to the risk. Search results are candidate clips for human review, not proof that the searched event occurred. Reka does not undertake to inspect every search, especially in customer-operated deployments. Customers are responsible for ensuring that searches involving protected traits, ideology, or subjective labels are lawful, appropriate to the context, and not used as the sole basis for consequential action against a person.
5. Risk classification and decision framework
5.1 Classification
Every use is classified before access to production data:
Prohibited: A use listed in Section 3 or a use whose residual risk cannot be reduced to an acceptable level. It may not proceed.
High risk: A use involving public-space monitoring, physical safety, enforcement-adjacent workflows, vulnerable populations, sensitive data, large-scale surveillance, or a plausible path to material rights or safety harm. It requires formal assessment and senior approval.
Moderate risk: A bounded use that can affect operations or people but has limited consequence, limited data, and meaningful human review. It requires documented owner approval and proportionate evaluation.
Low risk: Internal experimentation or low-consequence assistance using non-sensitive data, with no meaningful decision or rights impact. It still requires basic security, documentation, and acceptable-use controls.
A capability or deployment moves to a higher tier when its scale, autonomy, sensitivity, persistence, user base, or potential consequence increases.
5.2 Risk analysis
The assessment considers severity, likelihood, exposure, detectability, reversibility, scale, affected populations, and uncertainty. It evaluates at least:
physical and psychological harm;
civil-rights, equity, and accessibility harm;
privacy and surveillance harm;
security and misuse risk;
model reliability and operational risk;
legal and contractual risk;
reputational and public-trust risk; and
concentration of power or erosion of human accountability.
Assessments document inherent risk, controls, evidence of control effectiveness, residual risk, open issues, and the accountable person accepting residual risk. Uncertainty is not treated as proof of safety. Where potential harm is serious and evidence is weak, Reka applies a precautionary margin, narrows the use, strengthens safeguards, or declines deployment.
5.3 Approval gates
A high-risk deployment may proceed only when:
the use is not prohibited and has a legitimate, documented purpose;
data rights, privacy, security, and retention have been reviewed;
performance, robustness, fairness, and misuse evaluations meet approved criteria;
human oversight and operator training are in place;
the customer accepts contractual use restrictions and audit cooperation;
monitoring, incident response, rollback, and exit plans are operational; and
the designated approval authority accepts the documented residual risk.
No commercial deadline may waive a required gate.
6. Model and system lifecycle controls
6.1 Design and documentation
Each released model and material deployment configuration must have documentation appropriate to its risk, which may include:
intended and prohibited uses;
model architecture and major design choices at a level consistent with security and intellectual-property protection;
training and evaluation data summaries, sources, rights, transformations, and limitations;
evaluation methodology and results;
known failure modes and uncertainty;
prompt, threshold, camera, and system dependencies;
security and privacy controls;
human-oversight requirements;
version history, owner, approval, and retirement status; and
open risks and recommended mitigations.
Documentation artifacts may include a model card, system card, data sheet, risk assessment, threat model, evaluation report, change record, and deployment runbook. They must be version-controlled and retained according to Reka’s records policy.
6.2 Data development controls
Before data is used for training, tuning, or evaluation, Reka must document its origin, permitted uses, owner or steward, license or other legal basis, transformations, quality checks, known gaps, sensitive-data content, retention, and deletion requirements. Data access is limited to authorized roles.
Quality controls should detect corruption, duplication, leakage between training and test sets, mislabeled examples, inappropriate content, and material distribution gaps. Corrections must be traceable. Synthetic and third-party data must be identified as such and assessed for inherited bias and restrictions.
6.3 Evaluation and validation
Evaluation is deployment-specific and includes the end-to-end system. Depending on risk, it includes:
precision, recall, false-positive rate, false-negative rate, and alert volume;
calibration or threshold behavior where confidence scores are used;
latency, throughput, uptime, and resource use;
robustness to lighting, resolution, camera angle, weather, crowding, occlusion, motion blur, unusual objects, adversarial inputs, and out-of-distribution conditions;
prompt sensitivity and consistency across paraphrases;
fairness and error analysis across relevant groups and conditions;
privacy leakage and attempts to elicit prohibited inferences;
security testing, abuse testing, and red teaming;
usability testing with intended operators; and
failure-mode and human-factors testing, including automation bias and alert fatigue.
Acceptance thresholds are defined before final testing where practicable and tied to the harm of the use case. Aggregate accuracy alone is insufficient. Evaluation sets must be separate from training data and representative of the deployment environment. Material limitations are disclosed to the customer.
6.4 Fairness evaluation
Fairness is defined in relation to the use and its harms. For physical-security alerting, relevant measures may include false-positive and false-negative rates, alert burden, escalation rates, and time to correct an error across legally and ethically appropriate slices.
Testing should cover environmental and contextual factors that can act as proxies or create uneven performance, including lighting, camera placement, crowd density, mobility aids, body position, attire, head coverings, and occlusion. Where demographic evaluation is lawful, necessary, and ethically justified, data is used only in a controlled evaluation environment with access restrictions and privacy review.
If a material disparity is found, Reka will investigate root causes; improve data, prompts, thresholds, interface, or workflow; narrow or pause the use; and retest. A disparity may not be dismissed solely because a protected trait is not an explicit model input.
6.5 Explainability and traceability
Because a VLM can produce plausible but incorrect descriptions, an alert must not be presented as a bare conclusion. The system should preserve enough context for review, including the originating camera/time, relevant evidence window, alert definition, model and configuration version, and applicable threshold. Reka will explain system behavior at the level needed for operators, auditors, and affected stakeholders without exposing information that would compromise security or privacy.
6.6 Deployment, versioning, and change control
Every production release must use a unique model version and configuration identifier. Material changes to model weights, prompts, thresholds, camera layouts, data flows, integrations, or downstream actions require impact analysis and proportionate retesting. High-risk changes require reapproval. Approved versions must support rollback, and outdated or unsupported versions must have a deprecation and customer-migration plan.
Models are updated or retrained based on documented need rather than an arbitrary schedule. Triggers include measured drift, new failure modes, material data changes, new legal requirements, security findings, capability changes, and performance below acceptance criteria.
6.7 Production monitoring
Monitoring for high-risk deployments includes, as applicable:
precision and false-alert sampling confirmed by human review;
missed-event studies using approved methods;
alert volume, latency, uptime, and resource use;
performance by location, camera, time, and relevant fairness slices;
operator overrides, complaints, appeals, and harmful outcomes;
prompt and configuration changes;
unauthorized use or attempts to invoke prohibited capabilities;
data drift and changes in camera or environmental conditions; and
security events and third-party service degradation.
Monitoring has documented thresholds, owners, review cadence, and actions. Material breach of a threshold can trigger narrower operation, increased human review, rollback, suspension, customer notification, or decommissioning.
6.8 Retirement and exit
Decommissioning includes disabling endpoints and integrations, revoking access, returning or deleting data as required, preserving necessary audit records, notifying affected customers, and confirming that unsupported models are not left in production. Customer contingency and data portability obligations should be addressed contractually.
7. Privacy and data governance
7.1 Roles and lawful use
For each deployment, Reka and the customer will document their respective data roles and responsibilities, permitted processing, data ownership or stewardship, legal authority, subprocessors, cross-border transfers if any, and procedures for privacy questions and rights requests. The customer is responsible for having authority to provide camera data and for deploying the system lawfully; Reka is responsible for processing it only as authorized and for meeting its own legal and contractual obligations.
7.2 Data minimization and retention
Reka systems should process only the feeds, fields, frames, resolution, frequency, and time windows needed for the approved purpose. Where feasible, inference should occur without retaining raw video. Incident clips, metadata, prompts, outputs, and logs must have documented retention periods based on operational, legal, security, and audit needs. Retention “just in case” is not an acceptable purpose. Deletion must propagate to backups according to documented schedules and technical constraints.
7.3 Training-data boundary
Customer content, including video, images, prompts, outputs, and incident clips, will not be used to train or improve general Reka models unless the customer gives explicit written authorization and the use passes privacy, data-rights, security, and fairness review. Service-quality monitoring should use minimized or de-identified data where feasible.
7.4 Security controls
Controls are proportionate to data sensitivity and deployment risk and include, as applicable:
encryption in transit and at rest;
least-privilege role-based access and multifactor authentication;
tenant and environment separation;
secrets and key management;
logging and periodic access review;
vulnerability management, secure development, and dependency review;
controlled exports and download restrictions;
backup, recovery, and tested restoration;
vendor/subprocessor due diligence; and
incident detection, containment, investigation, notification, and remediation.
Security design should assume that model inputs can be adversarial and that outputs can expose sensitive information if not constrained.
7.5 Public-facing safeguards
Reka will support customers in providing understandable information about what the system does and does not do, consistent with security and operational needs. Deployments should offer an accessible route for questions and complaints and should explain when consequential outputs are machine-generated and subject to human review. Public communications must not exaggerate accuracy, capabilities, or expected outcomes.
7.6 Customer-controlled and on-premises deployment
Where supported, Reka offers deployment patterns that allow customers to operate Reka models inside infrastructure they own or control. This can reduce transfers of sensitive or proprietary material, help meet localization and confidentiality requirements, and give the customer direct control over network boundaries, encryption keys, access, logs, retention, and deletion. It is particularly relevant for unreleased media, licensed content, sports footage and analytics, confidential enterprise data, and security video.
Deployment architecture will be selected according to the use case, risk, technical requirements, and customer obligations. For customer-operated deployments, Reka will provide appropriate model documentation, integrity and version information, secure configuration guidance, update and vulnerability-notification processes, and support boundaries. The customer remains responsible for controls it operates, while Reka remains responsible for the model, software, documentation, and support commitments allocated to Reka by contract. Telemetry or support access from a customer-controlled environment must be documented, minimized, secured, and configurable consistent with operational needs.
8. Governance and accountability
8.1 CEO-led accountability
Product or deployment owner: prepares the use-case record, coordinates testing, documents risks and mitigations, and owns monitoring and remediation.
Relevant advisors: personnel responsible for security, privacy, legal, product, or engineering provide input when the risk falls within their expertise. Reka may use external counsel or specialists when the issue is material and internal expertise is insufficient.
Chief Executive Officer: Reka’s CEO, Dani Yogatama, is accountable for the company’s responsible AI governance and makes or delegates high-risk go/no-go and residual-risk decisions. Material incidents and unresolved high risks are escalated to the CEO and, where appropriate, existing board oversight.
Reka may combine roles to reflect its size, but the person accepting a high residual risk should not be solely the commercial owner of the deployment. The CEO works with relevant product, engineering, security, privacy, legal, commercial, and external stakeholders to ensure that Reka technology is developed and deployed responsibly, safely, and consistently with the company’s principles.
8.2 Responsible AI governance process
Reka operates a CEO-led responsible AI governance process proportionate to the company’s size, technology, and deployment risks. Under this process, Reka will:
maintain CEO accountability for this framework and its implementation;
assign a named owner to each high-risk use case;
maintain a concise risk register covering the use, risk tier, key controls, open issues, decision, and review date;
require a proportionate written risk assessment and CEO or delegated executive approval before Reka knowingly supports a high-risk production deployment;
engage the relevant internal stakeholders and, when appropriate, external counsel, specialists, customers, or affected-domain experts;
allow any employee to escalate a credible concern to the CEO or a designated executive; and
review this framework, material incidents, and the highest open risks at least annually and when a material trigger occurs.
This process will evolve as Reka’s scale, product capabilities, customer base, and legal obligations develop.
8.3 Speak-up and escalation
Employees and contractors must have a channel to raise safety, equity, privacy, legal, or ethical concerns without retaliation. A credible concern can pause launch or trigger review. Urgent risks to life, rights, or security are escalated immediately to the designated incident and executive owners.
8.4 Customer and partner accountability
Contracts and deployment plans should include approved uses, prohibited uses, data instructions, access controls, operator training, monitoring responsibilities, incident notification, audit cooperation, change-management duties, and rights to suspend or terminate misuse. Reka evaluates material third parties for security, privacy, reliability, compliance, and business-continuity risk and maintains an alternative or exit strategy proportionate to dependency.
For on-premises or otherwise customer-operated deployments, the contract and responsibility matrix must identify which party operates identity and access management, network and host security, logging, model updates, vulnerability remediation, backups, business continuity, retention, deletion, and incident response. Customer control of infrastructure does not remove Reka’s duty to communicate model limitations, safety-relevant updates, or material vulnerabilities in Reka-provided components.
8.5 Evidence and auditability
High-risk decisions must be reproducible from retained evidence: use-case record, risk assessment, data documentation, evaluation results, reviewer comments, approval, deployed versions, training records, monitoring reports, incidents, and changes. Reka will support reasonable customer assurance and audit requests subject to confidentiality, security, and intellectual-property protections.
9. Incident response, complaints, and remedy
9.1 Reportable events
Reportable AI incidents include actual or credible risk of:
death, injury, or unsafe operational response;
discriminatory treatment or a material disparity;
privacy breach, unauthorized access, or data misuse;
facial recognition, weapons targeting, or another prohibited use;
systematic false alerts or missed safety events;
loss of human oversight, unauthorized automation, or model behavior outside the approved scope;
security compromise, adversarial manipulation, or exfiltration; or
material legal, contractual, or public-trust harm.
9.2 Response
The incident owner will triage severity; preserve evidence; contain the issue; disable or narrow the system where necessary; coordinate with the customer; meet applicable notification obligations; investigate root cause; remediate; validate the fix; and document lessons learned. Severe or recurring incidents are reviewed by the CEO or a designated executive with relevant internal or external advisors.
9.3 Complaints and correction
Reka will maintain a process for customers and other appropriate stakeholders to report errors, bias, misuse, or privacy concerns. The deploying organization should provide the public-facing intake route. Complaints are tracked, risk-ranked, investigated, and resolved within defined service levels. Where feasible and appropriate, remedies may include correcting records, removing data, changing an alert definition, retraining users, adjusting or suspending a model, and explaining the resolution.
9.4 Crisis communication
For a material incident, Reka and the customer will identify a decision owner, factual source of truth, legal and privacy review, notification audience, timing, and update cadence. Communications should be timely, accurate, understandable, and clear about known facts, uncertainty, impact, containment, and next steps. Reka will not minimize a confirmed harm or speculate beyond available evidence.
10. Operational resilience, usability, and training
10.1 Performance and scale
Systems are tested under expected and peak load, degraded connectivity, component failure, and recovery scenarios. Capacity, compute, storage, latency, and cost are monitored against approved limits. Scaling must not silently reduce evaluation, logging, privacy, or human-review controls.
10.2 Business continuity and disaster recovery
High-risk services require documented recovery objectives, backups where appropriate, restoration procedures, degraded-mode behavior, customer communications, and periodic tests. Failure of the AI component should default to a known safe operational state and established non-AI procedures, not unchecked automation.
For customer-operated deployments, continuity plans must cover how model artifacts and approved configurations are securely restored, how critical fixes are delivered and verified, how unsupported versions are identified, and how operations continue if connectivity to Reka support services is unavailable.
10.3 User-centered design
Interfaces are evaluated with representative operators for comprehension, accessibility, alert fatigue, automation bias, workflow fit, and error recovery. Labels and confidence indicators must not overstate certainty. Feedback from users informs design changes and training.
10.4 Training
Before production access and periodically thereafter, users receive role-appropriate training on intended and prohibited uses, limitations, human review, privacy, fairness, security, escalation, incident reporting, and version changes. Completion is recorded. Privileged access can be removed for noncompletion or misuse.
11. Legal, regulatory, and policy compliance
Reka will maintain a process to identify and monitor laws, regulations, contractual duties, standards, and customer policies applicable to each deployment and jurisdiction. Legal review occurs before high-risk deployment and when the regulatory landscape or use materially changes. The review identifies obligations concerning surveillance, privacy and data protection, civil rights and nondiscrimination, accessibility, consumer protection, cybersecurity, records retention, public-sector procurement, labor, intellectual property, and AI-specific rules.
This framework is informed by risk-based approaches reflected in the NIST AI Risk Management Framework and ISO/IEC 42001, but this statement does not claim certification or complete conformity. Contractual or regulatory commitments must be documented separately and supported by evidence.
12. Innovation, obsolescence, and framework change
Reka will track material advances in model capability, evaluation, privacy-enhancing technology, security, law, and industry practice. New capability is assessed for both benefit and misuse before release. A model that becomes unsupported, insecure, materially less safe than a replacement, or unable to meet current requirements must be remediated, restricted, or retired.
This framework is reviewed at least annually and after a severe incident, material model or product change, new prohibited-use concern, major legal change, or significant external research finding. Changes require documented rationale and approval. Urgent safety changes may be fast-tracked, but must receive retrospective review. Material changes are communicated to affected teams and customers.
13. Minimum evidence package for a high-risk deployment
Before production approval, the deployment file should contain:
use-case and public-benefit statement;
system diagram and data-flow map;
AI/privacy/security/equity impact assessment;
model, system, and data documentation;
prohibited-use and misuse threat model;
evaluation plan, predefined acceptance criteria, and results;
fairness and accessibility analysis;
human-oversight workflow and operator materials;
privacy, retention, and deletion plan;
security review and open-risk record;
monitoring, incident, rollback, continuity, and exit plans;
legal/contractual review;
customer responsibilities and authorized-user list; and
approval decision, conditions, residual risk, and accountable owner.