AI that proposes clearly and acts carefully.

KOMERRA uses artificial intelligence to help businesses understand information, organize work, prepare records, identify possible next steps, and reduce repetitive administrative effort.

This Responsible AI framework explains the boundaries, safeguards, responsibilities, and governance principles that should apply when AI-assisted functionality is designed, configured, tested, deployed, monitored, or used through KOMERRA.

Responsible AI is not achieved by adding a warning beneath a model response. It requires clear authority boundaries, appropriate data handling, permission checks, human oversight, testing, monitoring, incident response, correction mechanisms, and accountability throughout the AI system lifecycle.

This page should be read together with the KOMERRA Terms of Service, Privacy Policy, Security & Trust page, Trust Centre, Data Processing Agreement, Acceptable Use Policy, Subprocessors page, and any feature-specific notice presented when an AI-assisted workflow is used.

KOMERRA is operated by KOMERRA Technologies Limited, a company registered in the Federal Republic of Nigeria with registration number 9681120.

KOMERRA may develop parts of its own AI orchestration, validation, extraction, retrieval, evaluation, and workflow systems while using approved third-party providers for language models, speech processing, optical character recognition, translation, image analysis, or other specialized capabilities.

The provider, model, configuration, location, and processing method available for a particular feature may depend on the deployment, Workspace settings, country, language, risk level, commercial plan, and technical availability.

Questions or concerns about an AI feature may be sent to support@komerra.app with “AI Concern” in the subject.

“AI feature” means a KOMERRA function that uses artificial intelligence, machine learning, generative models, language models, optical character recognition, speech processing, classification, recommendation, or similar automated techniques.

“AI Output” means information generated, extracted, summarized, translated, classified, predicted, recommended, drafted, or otherwise produced through an AI feature.

“AI input” means the instruction, prompt, message, image, document, voice note, business record, configuration, retrieved context, or other information supplied to an AI feature.

“High-impact action” means an action that may materially affect a customer, business record, payment status, financial commitment, communication, permission, security setting, legal obligation, publication, or another significant business outcome.

“Tool” means a controlled application capability that an AI workflow may request, such as searching records, preparing a document, creating a draft, updating an order, scheduling a reminder, or sending a communication.

“Human approval” means an intentional decision by an appropriately authorized person after receiving sufficient information to understand and review the proposed action.

KOMERRA’s approach to Responsible AI is guided by usefulness, human control, transparency, privacy, security, proportionality, reliability, accountability, and continuous improvement.

The level of control and review should reflect the significance of the action. A low-risk suggestion may require less intervention than a financial, external, destructive, permission-changing, security-sensitive, or legally significant action.

AI must not receive authority merely because it can produce convincing language. Authority comes from authenticated users, valid permissions, trusted business records, deterministic application rules, verified providers, and explicit approvals.

KOMERRA uses AI to interpret business language, extract structured details, summarize information, translate content, classify activity, prepare drafts, identify possible follow-ups, and recommend next steps.

AI is not the authoritative source for tenant identity, Workspace membership, user permissions, payment settlement, Credit balances, stock movements, tax rates, final prices, legal status, identity verification, provider status, or other trusted platform state.

Deterministic application code, authenticated context, authorized business records, configured rules, provider-confirmed results, and approved human actions remain authoritative for sensitive platform decisions.

An AI-generated statement does not change a business record until the applicable workflow, permission, validation, and approval requirements have been completed.

An AI feature must not invent authority, create permissions, override security controls, or represent an unverified event as confirmed.

KOMERRA separates the ability to understand or draft information from the authority to carry out the resulting action.

An AI feature may identify a possible order, but application rules must determine whether the customer and products exist, whether the quantities are valid, and whether the user may create the order.

An AI feature may draft a payment reminder, but an authorized user must determine whether the debt is accurate, whether contact is appropriate, and whether the message should be sent.

An AI feature may interpret uploaded payment evidence, but settlement must be confirmed through an authoritative bank record, payment provider, or permitted human verification process.

An AI feature may recommend a stock update, but trusted application logic must determine the affected product, quantity, transaction, and resulting inventory balance.

KOMERRA’s AI-assisted workflows should preserve a clear division of responsibility.

An important AI recommendation should provide enough information for an authorized user to understand what was identified and what will happen if the recommendation is approved.

Where appropriate, the interface should show the source material, extracted details, supporting business records, proposed action, affected customer or record, expected consequence, and whether approval is required.

Explanations should be proportionate to the significance of the action. A simple categorization may require less explanation than a payment-related decision, customer communication, permission change, public publication, or destructive operation.

An explanation should not be presented in a way that falsely implies certainty, independent verification, professional judgment, or guaranteed correctness.

Where a recommendation is based on retrieved business records, the relevant records or source references should be identifiable where practical.

Confidence indicators may be used to help users identify information requiring closer review.

A confidence score is an estimate produced by a model, rule, or evaluation process. It is not proof that the Output is correct.

A high-confidence result may still be wrong, and a low-confidence result may still contain useful information.

Low-confidence or conflicting results should invite clarification, correction, or additional evidence rather than being silently converted into final records.

Where important information is missing, ambiguous, inconsistent, or unsupported, the AI feature should identify the uncertainty instead of fabricating a complete answer.

The interface should avoid design patterns that pressure a user to approve uncertain Output without meaningful review.

High-impact actions should require an appropriately authenticated and authorized user and a workflow designed to support meaningful review.

AI must not silently perform a high-impact action merely because the action appears efficient, likely, or consistent with earlier behaviour.

The person approving the action should receive material information needed to understand what the action will do and which records, customers, providers, or systems will be affected.

A confirmation button should not be treated as meaningful human oversight where essential information is hidden, the outcome is unclear, the user lacks authority, or the interface is designed to obtain approval without genuine consideration.

The approving user should be able to review the intended action, affected records, material values, recipient, and expected consequence before approval.

Approval should be associated with the authenticated user, Workspace, time, workflow, and resulting action where appropriate.

A user must not approve an action outside the authority granted by the Workspace owner or applicable business process.

Where multiple approvals are required by a business’s internal policy, KOMERRA should not represent a single confirmation as satisfying every internal requirement.

An administrator may configure automation or approval rules only within the permissions and controls available to that administrator.

KOMERRA may support automated, conditional, recurring, or scheduled workflows where the Workspace owner or authorized administrator deliberately enables them.

An automated workflow must operate within defined permissions, triggers, scope, limits, templates, recipients, schedules, Credit availability, and safety rules.

The authorization to run an automated workflow does not permit the workflow to exceed the authority of the user or Workspace that configured it.

Businesses should periodically review enabled automations, connected providers, recipients, thresholds, templates, permissions, and outcomes.

An automated workflow should pause, fail safely, or request human review where material information is missing, inconsistent, high risk, outside the configured scope, or affected by a security concern.

Users should be able to disable an automation that is no longer appropriate, subject to completion or cancellation rules for actions already accepted for processing.

Some AI-assisted workflows may be capable of requesting controlled application tools or coordinating multiple steps to complete a task.

An AI model does not receive direct and unrestricted access to KOMERRA databases, infrastructure, credentials, providers, or administrative functions.

Available tools should be explicitly defined, allowlisted, scoped, validated, and permission checked.

Tool inputs must be validated independently of the model’s request. A model-generated tool request must not be trusted merely because it conforms to an expected structure.

Each tool should enforce tenant context, authorization, resource ownership, state requirements, limits, idempotency, and other relevant controls.

High-impact tool calls should require human approval or another specifically authorized control before execution.

A tool response should provide only the information reasonably necessary for the workflow rather than unrestricted access to surrounding records.

KOMERRA AI does not operate as a bank, payment institution, escrow service, or autonomous financial agent.

An AI feature must not independently initiate, route, withdraw, transfer, refund, or settle customer money merely because a user message or model Output appears to request it.

Customer payments displayed or recorded through a Mini Store remain between the customer, the business, the relevant bank, and the applicable payment provider.

KOMERRA Credit allocation must depend on trusted payment-provider verification and deterministic billing logic rather than model interpretation.

AI may assist with preparing payment instructions, matching references, extracting details, or identifying discrepancies, but the applicable financial workflow and authorized person remain responsible for the outcome.

An image, screenshot, transfer receipt, debit alert, teller, payment message, or other uploaded evidence may be incomplete, altered, duplicated, forged, reversed, or unrelated to the claimed transaction.

AI may extract information from payment evidence, such as an amount, payer name, reference, bank, or date, but the extracted information remains unverified.

A business should independently confirm settlement through its bank, authorized payment provider, or another authoritative financial record before releasing goods, issuing a final receipt, or marking an order as paid.

KOMERRA must not represent an AI extraction, browser redirect, or customer-uploaded document as equivalent to provider-confirmed settlement.

Suspected fraudulent payment evidence may be flagged, restricted, preserved, or escalated for review in accordance with applicable policies and law.

An AI feature must not gain access to a record or action that the authenticated user is not permitted to access directly.

Workspace membership, tenant context, assigned role, explicit permission, resource ownership, feature entitlement, and applicable business rules must be evaluated before protected information is accessed or changed.

Permissions must be enforced by trusted application services and tools rather than relying on the model to remember or interpret the rules.

An AI request must not be able to change the active tenant by supplying another business identifier in a message, document, link, prompt, or tool argument.

Administrative, billing, verification, security, support, and cross-Workspace tools require additional restrictions appropriate to their risk.

AI context for one Workspace must not include another Workspace’s private records merely because both businesses use the same model, provider, infrastructure, index, cache, or orchestration service.

Tenant identity should come from trusted authenticated context rather than untrusted model Output or user-supplied identifiers.

Retrieval systems, vector stores, search indexes, caches, files, message history, and business-memory systems must apply tenant-aware filtering and authorization before information is made available to an AI feature.

Cross-business tool targets, identifiers, file references, records, and retrieval results should be rejected unless a separately authorized cross-tenant administrative function applies.

Testing should include attempts to obtain another business’s information through direct prompts, indirect prompts, document content, manipulated identifiers, retrieval queries, file references, and tool arguments.

Messages, webpages, documents, files, product descriptions, customer communications, images, and retrieved records may contain instructions designed to manipulate an AI system.

Content processed by an AI feature is treated as data unless the workflow has explicitly authorized the content as an instruction source.

A document that says “ignore your rules” does not receive authority to change permissions, reveal secrets, select another Workspace, bypass approval, or invoke restricted tools.

KOMERRA may use instruction separation, input classification, system constraints, content filtering, tool allowlists, validation, context restrictions, confirmation requirements, and other safeguards to reduce prompt-injection risk.

Prompt-injection detection is imperfect and must not replace authorization, tenant isolation, output validation, tool restrictions, and human review.

Sensitive workflows should fail safely when instructions conflict, appear manipulated, request unauthorized data, or attempt to override trusted system rules.

Indirect prompt injection occurs when manipulative instructions are embedded in content that an AI feature is asked to read, summarize, retrieve, or analyze.

Potential sources include imported emails, connected-channel messages, customer attachments, invoices, websites, product descriptions, documents, screenshots, support messages, and retrieved knowledge-base content.

Retrieved content should not be allowed to redefine system policy, grant permissions, expose credentials, select unrestricted tools, or replace the authenticated user’s authority.

Where a workflow uses external or user-controlled content, the content should be isolated, minimized, labeled, filtered, or otherwise handled according to the risk of the intended action.

A high-risk action requested primarily by untrusted embedded content should require additional verification and human approval.

AI features should not receive passwords, private keys, payment-card security codes, database credentials, provider secrets, signing keys, recovery codes, or other authentication material unless an exceptional secure workflow specifically requires and protects that information.

Production secrets should not be inserted into model prompts, Business Content, ordinary support messages, source documents, retrieval indexes, or AI-visible logs.

Outputs should be filtered or restricted where they may expose credentials, private system instructions, confidential security configurations, internal access tokens, or another person’s private information.

An AI model must not be treated as an appropriate long-term secret-storage system.

Where accidental secret exposure is detected, the affected credential should be revoked or rotated rather than relying solely on deletion from visible conversation history.

KOMERRA should process only the information reasonably necessary to perform the requested AI function.

A workflow should not send an entire customer database, message archive, document library, or Workspace history where a smaller and more relevant selection is sufficient.

Data-minimization techniques may include selecting specific fields, redacting unnecessary identifiers, truncating irrelevant history, summarizing context, replacing direct identifiers, using structured values, or processing information locally where appropriate.

The information available to an AI feature should reflect the user’s permission and the purpose of the task.

Data minimization reduces risk but does not remove the need for lawful processing, security, provider governance, retention controls, and appropriate human review.

AI-assisted processing involving personal data remains subject to the KOMERRA Privacy Policy, Data Processing Agreement, applicable Workspace instructions, and data-protection law.

A business is generally responsible for having a lawful basis and legitimate purpose for customer, staff, supplier, and other personal information that it chooses to process through KOMERRA.

The existence of an AI feature does not create permission to collect excessive information, ignore privacy notices, repurpose customer data, retain information indefinitely, or disclose information unlawfully.

Sensitive personal data should only be processed where the workflow is necessary, lawful, proportionate, appropriately protected, and supported by any additional condition required by applicable law.

Users must not submit personal data to an AI feature merely to experiment, test curiosity, create unrelated profiles, or make prohibited decisions about an individual.

KOMERRA may use approved third-party providers for language models, speech processing, translation, image analysis, document extraction, safety filtering, or related AI services.

Provider selection should consider the processing purpose, information involved, contractual terms, model behaviour, security, privacy, retention, service location, availability, incident response, and ability to support KOMERRA’s obligations.

Providers should receive only the information reasonably necessary to perform the selected function.

A provider does not receive independent authority to communicate with customers, alter business records, make financial commitments, or operate a Workspace merely because it processes an AI request.

Material providers processing personal data are identified through the Subprocessors page, Privacy Policy, Data Processing Agreement, or an applicable enterprise agreement.

Provider availability, capabilities, models, terms, and locations may change. Material changes should be handled through the applicable provider-governance and notification process.

Production deployments should enable only approved AI providers, models, credentials, endpoints, regions, and configurations.

Development, test, staging, and production credentials should be separated.

A fallback provider should not receive information merely because the primary provider fails unless the fallback is approved for the relevant data, purpose, location, and risk level.

Provider selection should not be controlled solely by untrusted user input or model Output.

Configuration changes affecting models, prompts, retention, tool access, safety filters, geographic processing, or data usage should be reviewed and tested before production use.

Mock, demonstration, or fallback behaviour should be clearly distinguished from live production processing where the distinction could affect a user’s decision.

KOMERRA does not use identifiable private Workspace Business Content to train unrelated general-purpose AI models unless the Workspace owner knowingly and expressly opts into a separately explained programme.

KOMERRA seeks to use provider offerings and contractual terms that restrict provider use of submitted Business Content for unrelated general-model training.

KOMERRA may use synthetic information, public test data, voluntarily provided feedback, aggregated information, and appropriately de-identified information to evaluate and improve AI functionality.

Where human review of an AI interaction is necessary for support, safety, investigation, or quality assurance, access should be limited to authorized personnel or providers with a legitimate need and appropriate confidentiality obligations.

An optional improvement programme should explain what information is used, for what purpose, for how long, with which providers, and how participation can be withdrawn.

KOMERRA may provide a Business Memory or similar feature that helps preserve approved facts, preferences, records, or context for future business workflows.

Business Memory should distinguish user-approved or authoritative business information from temporary model interpretation, unverified extraction, or speculative Output.

Information should not become a permanent business fact merely because a model mentioned it repeatedly.

Businesses should be able to review, correct, remove, or update retained business information where appropriate.

Memory access must remain tenant isolated, permission aware, purpose limited, and subject to retention and deletion controls.

Sensitive information should not be retained in AI memory merely because it appeared in a prompt, conversation, attachment, or temporary processing result.

Where an AI feature uses Workspace records, policies, documents, conversations, or other retrieved information, retrieval should be limited to sources the user is authorized to access.

The retrieved information should be relevant to the task and should not include unrelated records merely because they contain similar words.

Where practical, important answers or recommendations should identify the relevant record, source, date, or business context on which they rely.

A retrieved source may itself be inaccurate, outdated, manipulated, incomplete, or unauthorized. Retrieval does not eliminate the need for source evaluation and human review.

Where sources conflict, the AI feature should identify the conflict or request clarification rather than silently selecting the most convenient source.

Authoritative system records should take priority over unverified notes, generated text, customer claims, or model assumptions.

AI Output intended for application processing should use clearly defined structures, fields, types, and allowed values where practical.

Structured Output must still be validated by application code before it is stored, displayed as confirmed, or passed to a protected tool.

Validation may include required fields, data types, identifiers, allowed states, currency, amount, date, tenant ownership, permission, product existence, customer existence, and business-rule checks.

Invalid, incomplete, conflicting, or out-of-scope Output should be rejected, corrected, or routed for human review.

Schema compliance does not prove factual accuracy. A well-formed but incorrect amount, customer, product, date, or recipient remains incorrect.

Financial and operational calculations should be performed or revalidated by deterministic application code.

Calculations may include line totals, discounts, taxes, invoice totals, Credit deductions, stock adjustments, balances, due dates, payment allocation, and usage limits.

AI may help identify values from source material, but the application should calculate the resulting totals and verify that the inputs are valid.

Rounding, currency, tax, quantity, unit, and pricing rules should come from configured business logic rather than model improvisation.

Where the underlying inputs remain uncertain, the calculated result should remain subject to review rather than being represented as final.

No AI model is infallible. AI Output may be incorrect, incomplete, misleading, inconsistent, biased, outdated, duplicated, or unsuitable for a particular business purpose.

Quality can be affected by unclear language, low-quality images, background noise, accents, handwriting, missing context, unusual transactions, incorrect records, unsupported file types, provider limitations, or changes to model behaviour.

Users should review names, products, quantities, prices, currencies, taxes, balances, dates, addresses, delivery details, payment status, document type, and intended recipients before approval.

KOMERRA should not advertise an accuracy level as universal unless the metric, dataset, languages, scope, conditions, and evaluation date are clearly stated.

An AI feature should not conceal known limitations that materially affect how a user should interpret or review its Output.

Business communications may use formal English, Nigerian English, Pidgin, Yoruba, Igbo, Hausa, abbreviations, voice notes, code-switching, slang, local product names, and other informal or multilingual forms.

KOMERRA may support selected languages and language combinations, but support levels and accuracy may differ according to the model, feature, input quality, language pair, dialect, terminology, and context.

Language detection and translation may be wrong and should not be treated as authoritative where the meaning affects payment, quantity, delivery, complaint handling, legal rights, or another material decision.

Mixed-language and culturally specific inputs should be included in testing for relevant markets.

A user should be able to correct a translation, transcription, extracted meaning, customer name, local expression, or other misunderstood information.

KOMERRA should not represent a language as fully supported merely because the model can occasionally generate text in that language.

Voice notes and audio may be processed to produce transcripts, translations, summaries, classifications, or structured business details.

Speech recognition may be affected by noise, multiple speakers, accent, language switching, recording quality, speed, pronunciation, and specialized terminology.

Automatically generated transcripts should be reviewed before they are used to create records, contact customers, issue documents, or make a material decision.

The business is responsible for having an appropriate lawful basis to record, upload, or process another person’s voice or conversation.

KOMERRA does not treat a transcript as more authoritative than the underlying recording or the person who made the statement.

KOMERRA may use optical character recognition, image analysis, and document extraction to identify text and structured information in screenshots, receipts, invoices, forms, product images, and other files.

Extraction quality may be affected by cropping, blur, glare, shadows, handwriting, design layout, image compression, missing pages, overwritten values, or manipulated content.

Extracted information should be compared with the original file before being approved for a material workflow.

A document can be accurately transcribed and still be forged, expired, misleading, or unrelated to the claimed person or transaction.

Document extraction is not the same as document authentication, identity verification, payment confirmation, legal validation, or regulatory approval.

KOMERRA AI should not be designed or used to produce unlawful or unjustified discrimination against an individual or group.

Features should be evaluated for contextually relevant disparities, particularly where Output may influence access, prioritization, treatment, employment, credit, insurance, essential services, or another significant opportunity.

Business data may reflect historical bias, incomplete records, unequal treatment, or proxy characteristics. A model’s use of such information does not make the resulting recommendation fair.

Protected or sensitive characteristics should not be inferred, generated, or used for decision-making unless the processing is lawful, necessary, appropriate, and supported by relevant safeguards.

Users must not use KOMERRA to rank, exclude, target, or disadvantage people through unlawful profiling or discriminatory criteria.

Where a fairness concern is identified, KOMERRA may restrict the feature, modify the workflow, require human review, improve testing, or discontinue the affected use.

KOMERRA is primarily a business-management assistant and is not intended to independently make employment, credit, insurance, healthcare, legal, education, housing, or essential-service decisions about individuals.

Businesses must not use AI Output as the sole basis for a decision producing a legal or similarly significant effect on a person unless the processing is lawful and all required safeguards are provided.

Where applicable, safeguards may include meaningful information about the decision, human intervention, the ability to express a point of view, correction of inaccurate information, and the ability to contest the outcome.

A human reviewer must have genuine authority and sufficient information to change the outcome rather than merely confirming the model by default.

The availability of an AI classification or recommendation does not mean that KOMERRA has approved its use for a regulated or high-impact decision.

KOMERRA is designed as a business-management service and is not directed to children.

AI features involving children or vulnerable people require particular care because these individuals may face greater risks from profiling, manipulation, inaccurate decisions, excessive data collection, or inappropriate communication.

Businesses must not process a child’s information through an AI feature unless they have lawful authority, an appropriate purpose, required notices or consent, and safeguards suitable for the child.

AI should not be used to exploit vulnerability, pressure a person, conceal commercial intent, or encourage harmful behaviour.

Features involving children, guardianship, healthcare, education, employment, or similarly sensitive contexts may be restricted or require additional assessment.

KOMERRA AI does not replace a lawyer, accountant, auditor, tax adviser, financial adviser, medical professional, insurer, employment specialist, or other qualified professional.

AI-generated documents, summaries, calculations, recommendations, or explanations may not reflect every law, contract, tax rule, accounting standard, professional obligation, regulatory requirement, or fact relevant to a business.

Users should obtain qualified professional advice where an error could create a material legal, financial, regulatory, health, employment, or contractual consequence.

An Output should not be represented as professionally reviewed, legally approved, audited, certified, or guaranteed unless that review or approval genuinely occurred.

AI Output may resemble content created for other users and may not be unique.

Users are responsible for reviewing generated content for intellectual-property, confidentiality, privacy, attribution, trademark, and contractual concerns before publishing or using it commercially.

KOMERRA should not represent AI Output as guaranteed to be free of third-party rights.

Users must not ask KOMERRA to reproduce protected material unlawfully, remove ownership information deceptively, imitate confidential material, or misrepresent another person’s work as their own.

Generated product descriptions, advertisements, documents, and public content must remain accurate and must not make misleading claims about a business, product, certification, customer, or provider.

KOMERRA AI must not be used for unlawful, fraudulent, abusive, deceptive, exploitative, or security-compromising purposes.

An AI feature may refuse, limit, defer, or request clarification where a request appears unlawful, unsafe, unauthorized, deceptive, outside the feature’s scope, or inconsistent with applicable policy.

A workflow should fail safely where required permission, tenant context, provider verification, material information, or human approval is unavailable.

A refusal should not reveal confidential security rules, another person’s information, protected system instructions, or details that would help bypass the safeguard.

Where possible, a refusal should explain the general reason and identify a safer or authorized path for completing the legitimate part of the task.

Users must not repeatedly reformulate a request in order to evade a safety, permission, verification, or policy control.

Material AI features should undergo evaluation proportionate to their purpose, affected information, level of autonomy, potential harm, and expected use.

Evaluation should consider accuracy, reliability, hallucination, unsafe Output, permission enforcement, tenant isolation, prompt injection, data leakage, fairness, language performance, provider failure, human review, and recovery behaviour.

Testing should use representative business scenarios, supported languages, ambiguous inputs, malformed information, low-quality files, edge cases, and adversarial attempts.

A feature should not be represented as production ready merely because it works on a small number of ideal examples.

Evaluation results should inform release conditions, confidence thresholds, user warnings, approval requirements, monitoring, usage limits, and rollback plans.

KOMERRA may classify AI features according to the nature and potential effect of the workflow.

Factors may include whether the feature is internal or customer facing, advisory or action taking, reversible or irreversible, financial or non-financial, private or public, and whether it affects permissions, security, personal data, or legal rights.

Higher-risk workflows should receive stronger controls, more extensive testing, clearer explanations, stricter permissions, lower autonomy, additional monitoring, and meaningful human approval.

A feature’s risk classification may change when its tools, data, users, scale, model, automation, or intended purpose changes.

Risk classification should not be based solely on the name of the model or provider. The actual workflow and consequence matter.

KOMERRA may conduct an AI impact assessment, Data Privacy Impact Assessment, security review, or combined risk assessment before deploying a higher-risk AI feature.

An assessment may consider the purpose, necessity, proportionality, people affected, personal data, model provider, training and evaluation information, expected benefits, foreseeable misuse, potential harms, human oversight, security, fairness, transparency, retention, and complaint mechanisms.

An assessment should identify controls, responsible owners, remaining risks, monitoring requirements, and conditions for deployment.

Where a risk cannot be reduced to an acceptable and lawful level, KOMERRA may redesign, restrict, delay, or discontinue the affected feature.

An impact assessment is not a one-time exercise where material conditions subsequently change.

Changes to a model, provider, prompt, system instruction, retrieval source, tool, schema, confidence threshold, automation rule, or safety control can materially change AI behaviour.

Material changes should be reviewed, tested, documented, and monitored before or immediately after controlled deployment according to the risk.

A model upgrade should not be assumed to be safer or more accurate for every KOMERRA workflow merely because it is newer or larger.

Where practical, KOMERRA should preserve model or configuration identifiers sufficient to investigate material Output and compare behaviour across releases.

Rollback, disablement, provider switching, or other containment options should be available for material failures where technically feasible.

AI governance continues after a feature is released.

KOMERRA may monitor operational signals such as extraction success, correction rate, rejection rate, low-confidence frequency, tool failure, safety blocks, provider errors, latency, cost, human approval, complaints, and recurring error patterns.

Monitoring should be designed to reduce unnecessary exposure of private Business Content and should remain subject to access and retention controls.

A rise in errors, unsafe Output, unexpected tool use, tenant-isolation concerns, provider changes, or user complaints may result in additional review, reduced functionality, stricter confirmation, rollback, or temporary disablement.

Metrics should be interpreted in context. A high approval rate does not prove correctness where users approve without reviewing the Output.

Sensitive AI workflows should create operational or audit records appropriate to the event.

Relevant records may include the authenticated user, Workspace, feature, model or provider reference, input category, retrieved source references, proposed action, validation result, confidence, approval, rejection, correction, tool request, final action, timestamp, and error status.

Audit records should be protected from unauthorized access, alteration, and unnecessary retention.

Auditability does not require permanent storage of every prompt, private message, or model intermediate result where that storage is unnecessary or disproportionate.

Responsibilities for approving features, reviewing risk, managing providers, responding to incidents, and remediating failures should be assigned rather than left implicit.

Recurring AI failures should not be treated as isolated user mistakes where they indicate a systematic problem.

KOMERRA may investigate patterns involving the same language, document type, workflow, product category, provider, model, prompt, tenant boundary, permission, or tool.

Corrective action may include changing prompts, improving validation, adjusting thresholds, adding examples, restricting a feature, requiring additional confirmation, changing providers, improving documentation, or disabling the workflow.

A user correction may be used to improve the current record or workflow without automatically authorizing unrelated use of the underlying private information.

Material corrective actions should be tested and monitored to ensure that they do not create new risks elsewhere.

An AI incident may include unauthorized disclosure, cross-tenant retrieval, harmful or deceptive Output, inappropriate tool execution, repeated financial error, failure of human approval, prompt-injection success, provider misuse, or another material AI-related failure.

Potential incidents should be assessed according to affected people, Workspaces, information, actions, duration, reversibility, legal obligations, and potential harm.

KOMERRA may contain an AI incident by disabling a feature, blocking a model or provider, revoking credentials, limiting tools, stopping automation, restricting affected Accounts, or increasing approval requirements.

Relevant evidence should be preserved where necessary to investigate the cause and support remediation.

Where an AI incident also constitutes a security or personal-data incident, the applicable security, privacy, contractual, and notification procedures apply.

Material incidents should lead to documented lessons, corrective actions, ownership, testing, and follow-up review.

Users should be able to correct, reject, or replace material AI-extracted information before approval in workflows requiring review.

A correction should update the intended business record without silently rewriting the original source material.

Where appropriate, the activity history should distinguish the initial extraction from the user-approved value.

Rejecting a suggestion should not create a financial, external, destructive, or permission-changing effect unless the user separately approves such an effect.

Repeated corrections may be used as an operational signal that a workflow requires additional evaluation.

Where an AI-assisted process materially affects a person, the affected person should have an appropriate way to raise a concern, provide relevant information, or request review where required by law or the circumstances.

A review should be performed by a person with sufficient information and authority to meaningfully reconsider the outcome.

The reviewer should not treat the model’s Output as presumptively correct merely because it was generated automatically.

KOMERRA may refer a request to the relevant business where the business controls the underlying customer, staff, order, or decision information.

KOMERRA may directly review matters involving platform-controlled Account security, billing, access, verification, or AI governance.

Users may report AI Output that is inaccurate, harmful, confusing, biased, unsafe, privacy-invasive, unauthorized, or inconsistent with the intended workflow.

Reports may be sent to support@komerra.app with “AI Concern” in the subject.

A useful report should include the affected Account or Workspace, feature, approximate time, relevant record or request identifier, expected behaviour, observed behaviour, and the potential impact.

Do not include passwords, private keys, payment-card security codes, recovery codes, or unnecessary identity documents in an ordinary support message.

KOMERRA may request additional information, preserve relevant records, restrict a feature, involve an appropriate provider, or take other proportionate action while investigating.

Reporting a genuine AI concern will not by itself result in retaliation or loss of access.

Responsible AI is shared between KOMERRA and the businesses and users operating AI-assisted workflows.

KOMERRA is responsible for the platform controls within its scope. Businesses remain responsible for the information they submit, permissions they assign, configurations they enable, and business decisions they approve.

Businesses should maintain reasonable fallback procedures for important operations where an AI feature, provider, connected channel, network, device, or KOMERRA service is unavailable.

A business should not depend exclusively on AI for a legal deadline, emergency communication, payment confirmation, irreversible financial decision, or other critical activity without an appropriate alternative.

Fallback procedures may include manual review, independent bank verification, alternative customer-contact methods, retained source records, document reconciliation, and delayed approval.

An AI outage or provider failure should not automatically convert an unverified event into a confirmed business record.

KOMERRA’s Responsible AI programme should assign ownership for AI policy, feature approval, provider review, security, privacy, evaluation, monitoring, incident response, complaints, and corrective action.

Material AI systems should be inventoried with information such as their purpose, owner, users, provider, model, data categories, tools, risk level, approval requirements, and current status.

Governance records should distinguish production features from prototypes, demonstrations, internal experiments, disabled systems, and planned capabilities.

Higher-risk exceptions should be documented, time limited where appropriate, approved by authorized personnel, and reviewed.

Responsible AI governance should be integrated with security, privacy, legal, engineering, product, support, and operational processes rather than operating as an isolated policy exercise.

KOMERRA may use recognized Responsible AI and risk-management frameworks as references when designing governance, testing, transparency, human oversight, security, privacy, monitoring, and accountability practices.

Using principles or controls from a framework does not automatically constitute certification, regulatory approval, independent assurance, or complete conformity with that framework.

KOMERRA should only claim a formal assessment, certification, audit, or validation where the relevant process has genuinely been completed and the published statement accurately describes the date, scope, organization, systems, and limitations.

Provider certifications and assurance reports apply to the provider’s defined scope and do not automatically certify KOMERRA’s application, configuration, workflows, or customer use.

As independent assessments become available, KOMERRA may publish appropriate summaries or make controlled evidence available to eligible enterprise customers under confidentiality.

KOMERRA’s Responsible AI programme is designed to support applicable privacy, security, consumer-protection, contractual, and other legal obligations relevant to the platform.

The Nigeria Data Protection Act includes safeguards concerning certain decisions based solely on automated processing of personal data, including profiling.

Whether another AI law, sector rule, professional requirement, or regulatory obligation applies depends on the country, business, industry, information, workflow, people affected, and consequence of the use.

A business remains responsible for determining whether its intended use of an AI feature is lawful and appropriate for its circumstances.

The availability of an AI feature does not constitute legal approval for every possible use of that feature.

KOMERRA does not claim that AI Output is always correct, complete, unbiased, unique, current, or suitable for every purpose.

KOMERRA does not claim that a confidence score proves accuracy.

KOMERRA does not claim that an AI extraction verifies identity, payment, ownership, authenticity, legal status, or regulatory compliance.

KOMERRA does not claim that human confirmation eliminates every possibility of error.

KOMERRA does not claim that a model provider’s certification automatically certifies KOMERRA.

KOMERRA does not claim that an AI feature is autonomous merely because it can coordinate multiple controlled steps.

KOMERRA does not claim formal Responsible AI certification, regulatory approval, or independent assurance unless current and appropriately scoped evidence exists.

KOMERRA may update this framework when AI features, providers, models, tools, risks, laws, guidance, architecture, or operating practices change.

A material change to an AI feature may require updated evaluation, provider review, privacy assessment, security review, user notice, workflow controls, or human-approval requirements.

Where a change materially affects the way personal data is processed, the applicable Privacy Policy, Data Processing Agreement, Subprocessors page, or feature notice should also be updated where required.

A feature that is removed, restricted, disabled, or no longer verified should not continue to be described as universally available or implemented.

Historical versions may be retained for accountability and reference.

Questions, complaints, and concerns about KOMERRA AI may be sent to support@komerra.app.

Use the subject “AI Concern” for inaccurate, unsafe, biased, confusing, unauthorized, or harmful Output.

Use the subject “Security Report” where an AI workflow may expose another person’s information, cross a tenant boundary, bypass permissions, execute an unauthorized tool, reveal a secret, or create another security risk.

Use the subject “Privacy Request” where the concern relates to access, correction, deletion, objection, automated decision-making rights, consent withdrawal, portability, or another personal-data matter.

Include the affected Account or Workspace, feature, approximate time, relevant record or request identifier, expected behaviour, observed behaviour, and potential impact where available.

Do not send passwords, private keys, recovery codes, payment-card security codes, or unnecessary identity documents through ordinary email.