Contact Us
JAENVI
AI Governance

AI Can Act.
People Remain Accountable.

Put AI to work with clear rules for data, decisions and automated actions. Governance makes those rules part of how the system is built and operated.

Our eight engineering practices translate AI governance into day-to-day development and operations. They draw on Japan’s AI Guidelines for Business (Version 1.2) and are tailored to each engagement.

01 No model training with client data without consent.

Your data is not used for training or fine-tuning without express written agreement. We review external AI service terms to guard against unauthorized training use.

02 Human accountability for high-impact actions.

We define what AI can do autonomously, where human approval is required and who remains accountable.

03 Outputs and actions can be reviewed.

We design for traceability: source references and records of outputs, decisions and agent actions, where supported by the system.

Explore Our Eight Governance Practices
Scope

Security Protects Information.
Governance Guides AI Behavior.

Information security and AI governance are complementary. Security protects information and systems; AI governance addresses how models and agents are selected, evaluated, authorized, and monitored.

Information Security

How is enterprise data protected?

Data handling locations, access permissions, approved services, secure development practices, and incident response govern how information is protected throughout a project.

View Information Security
AI Governance

What is AI allowed to do—and how is it checked?

Data-use rules, model evaluation, permitted actions, human oversight, traceability, and AI-specific security tests help keep system behavior within agreed boundaries.

Implementation Rules

Eight Practices for Responsible Enterprise AI.

Each practice describes our intended control approach, how it is applied in projects, and the documentation that can support a customer’s technical and risk review. Specific controls are agreed according to the system and its risk profile.

01

Handling client data

Customer Data

We use entrusted client data only for agreed project purposes. Training or fine-tuning on that data requires an explicit written agreement covering the intended use.

In practice

  • By default, we do not use data for training or fine-tuning. If we do, the target data, purpose, retention period and deletion conditions are set out in the contract or a memorandum.
  • For each project, we define which categories of data may be sent to external LLMs (may be sent / may be sent after masking / may not be sent). The categories are documented in a data handling classification table, which we submit for your approval.
  • Personal information, sensitive information, and trade secrets are classified as “may not be sent” by default. Any exception requires an agreed assessment of the data, processing location, provider conditions, and safeguards. Masking or pseudonymization alone does not necessarily remove personal-data obligations.
  • Where external AI services are not permitted, we can propose self-hosted open-weight models in an agreed environment, including an environment controlled by the client where required.
  • The retention period for inference logs and the region where they are stored are set for each project.

What we can provide

Data handling classification table, memorandum on use for training, log retention specification

02

Model selection

Vendor-Neutral Architecture

We evaluate models against project requirements, including security, quality, latency, and total cost, and document the rationale for our recommended configuration.

In practice

  • Where model choice materially affects the solution, we compare suitable candidates against representative tasks and document the results. We do not select a model solely because it is the newest.
  • Your constraints (Japan regions only, no data leaving your environment, on-premises) are the first filter we apply.
  • For self-hosted configurations, we assess techniques such as quantization and task-specific optimization against the available hardware and quality requirements.
  • Where feasible, we separate application logic from model-provider interfaces to reduce vendor dependence. Model changes still require compatibility checks and regression testing.
  • We compare costs not only by per-inference price but by expected monthly cost, including projected usage and retries.

What we can provide

Model comparison table (evaluation criteria, scores, reasons for selection), architecture diagram showing how models can be switched

03

Human oversight

Risk-Based Autonomy

We define the scope of AI autonomy according to business impact and risk. Actions requiring human approval, escalation, or additional safeguards are agreed during system design.

In practice

  • During design, we identify the accountable business role and the approval or escalation requirements for each relevant process.
  • Operations are assessed by impact, reversibility, and the consequences of error. High-risk or irreversible actions require approval or equivalent agreed controls. Routine, bounded actions—including eligible automated customer responses—may operate without per-action approval when the design permits it.
  • Agent tools and permissions are defined in advance and checked at execution time. Unauthorized operations are blocked through access controls and tool allowlists.
  • For decisions that require review, we present relevant evidence, limitations, or uncertainty indicators where available and design review flows to discourage automatic approval.
  • Escalation and handoff conditions are specified in the operational design, including how the system responds when it cannot safely complete a task.

What we can provide

Approval flow diagram, list of tool permissions, list of escalation conditions

04

Accuracy and evaluation

Testing & Acceptance

We establish fit-for-purpose evaluation criteria before deployment. Acceptance obligations for contracted development and exploratory success criteria for PoCs are defined separately; individual AI outputs cannot be guaranteed.

In practice

  • We prepare a representative evaluation set using approved client data or suitable test data and run benchmarks before deployment.
  • Depending on the use case, we evaluate task success, factual grounding, source attribution, response time, appropriate refusals, and escalation behavior using documented metrics.
  • Target thresholds and, where applicable, acceptance criteria are agreed according to the business risk and recorded in the evaluation plan or test specification.
  • For material model or prompt changes, we run regression tests against a controlled evaluation set and assess results against agreed tolerances before release.
  • Where ongoing evaluation is part of the engagement, we review production samples or monitored indicators and report findings through the agreed governance process.

What we can provide

Evaluation plan, benchmark results report, regression test results

05

Traceability

Evidence & Audit Trails

We design appropriate traceability into AI workflows so relevant outputs and agent actions can be investigated within agreed logging, privacy, and retention constraints.

In practice

  • Where source-backed answers are supported, we provide citations or references to the underlying documents or passages.
  • We define audit-log fields by use case. They can include timestamps, actor identity, model and version, referenced sources, tool actions, and approval events. Sensitive inputs and outputs are logged only as permitted by the agreed data-handling policy.
  • For multi-step agents, execution traces can capture the relevant steps, tool calls, and outcomes needed for investigation.
  • Log retention periods, access rights and export methods are agreed with you.
  • Logs containing personal information are handled under the rules described on our Information Security page.

What we can provide

Log field definitions, sample audit logs, retention and deletion procedures

06

AI security

AI-Specific Threat Controls

We apply layered controls to address AI-specific risks, including prompt injection, unauthorized tool use, data leakage, and unsafe knowledge ingestion.

In practice

  • Prompt injection: Retrieved documents and external content are treated as untrusted input. Instruction boundaries, tool permissions, and runtime checks are used together rather than relying on prompts alone.
  • Data leakage: Retrieval respects the user’s access permissions, and authorization is also enforced for tool execution and sensitive operations. We test for unintended information disclosure.
  • Access control: Where supported by the customer environment, we integrate with existing identity and access-management systems and apply least-privilege permissions.
  • Tool and operation authorization: We define approved APIs, tool capabilities, and operation scopes. Write actions are subject to risk-based authorization and approval controls.
  • Data poisoning: We establish permitted ingestion sources, record provenance where supported, and assess how changes to knowledge sources may affect system behavior.
  • Before release, we verify these points with test cases that include adversarial inputs.

What we can provide

List of AI security test items, test results, permission design document

07

Model change management

Change Control

Material changes to models, prompts, or providers are evaluated and managed through an agreed change-control process, including customer notification or approval where required.

In practice

  • Model versions, prompts and parameters are under configuration management, and we keep a change history.
  • Before a change, we assess its impact and present our proposal together with comparison results on the evaluation set.
  • Production changes follow the agreed approval process. When technically feasible, we use staged rollout and maintain a rollback or recovery plan.
  • We monitor published provider changes and plan migrations when discontinuations or material compatibility changes are identified.
  • When we update the models in our own products, we announce the scope of impact in the release notes.

What we can provide

Change impact assessment, comparative evaluation results, release notes

08

Use of third-party AI services

Provider Due Diligence

Any proposed third-party AI service is evaluated for data use, retention, processing locations, security terms, and suitability for the project. The approved service configuration is documented.

In practice

  • For each project, we list the services to be used and their purposes, and present the list to you before the contract.
  • We assess model-training terms, available data controls, retention, processing locations, subprocessors, relevant security assurances, and service restrictions.
  • For client data, we select service configurations whose applicable terms prohibit its use for provider model training unless the client expressly authorizes a different arrangement.
  • For projects where sending data externally is not permitted, we propose a configuration that does not use external services.
  • We review material changes to service conditions and notify clients where such changes affect the agreed project controls.

What we can provide

List of services used (purpose, data sent, region, whether data is used for training)

Boundaries & Responsibilities

Clear Boundaries. Defined Responsibilities.

Responsible AI also means being clear about limitations, contractual commitments, and where human judgment remains necessary.

Generative AI can produce incorrect or inconsistent results. We do not guarantee individual outputs. Development acceptance is assessed against the criteria agreed in the contract; PoC objectives support feasibility decisions and are not automatically acceptance obligations.

We cannot control third-party models’ internal training processes or future provider changes. We evaluate service terms, monitor relevant changes, and propose alternatives when required by project constraints.

Autonomy is bounded by the approved use case. Routine tasks may be automated under defined rules, while higher-risk or irreversible decisions require appropriate human oversight or explicit authorization.

For sensitive use cases that affect individuals—such as recruitment or personnel evaluation—we assess the purpose, fairness, applicable obligations, safeguards, and the appropriate role of human reviewers before agreeing on a design.

FAQ

AI Governance: Frequently Asked Questions.

Answers to common questions about data use, human oversight, testing, traceability, and operational controls. Project-specific arrangements are defined in the relevant agreement.

Do you use client data to train models?

Not without explicit written agreement. We use entrusted data only for agreed project purposes and do not authorize external AI providers to use client data for model training under our standard configurations.

Any training or fine-tuning use must specify the data, purpose, retention, and deletion terms and receive the client’s written consent.

What data is sent to external LLMs?

We classify data by what may be sent, what requires safeguards, and what must remain within the approved environment. Personal information, sensitive data, and trade secrets are restricted by default; masking alone does not automatically remove personal-data obligations.

External service use and processing locations are agreed before deployment. Where external AI services are prohibited, we can propose a self-hosted solution in the environment agreed for the project.

Can you tell us which models and versions you use?

Yes. We document the selected models and versions, the rationale for selection, and relevant comparative evaluations. Runtime records can capture model versions where logging is enabled under the project configuration.

Will the system behave differently when a model is updated?

Yes. Model and prompt changes can affect behavior. We assess material changes and run regression evaluations against agreed quality and risk thresholds before release.

Production changes follow the agreed approval process, with staged release and rollback arrangements where technically feasible.

Who is responsible if the AI gives a wrong answer?

Responsibilities depend on the use case and the agreed contract. During design, we define the accountable business roles, the actions AI may take autonomously, and any required human approvals. Technica AI’s delivery obligations are measured against the criteria agreed for the engagement.

Acceptance criteria, responsibilities, and remedies are determined by the project agreement and the applicable engagement terms.

Can we check the basis for an output?

Where supported, knowledge-based answers include source references. Audit records can capture relevant timestamps, model versions, referenced sources, approvals, and actions, subject to agreed privacy and retention controls.

Multi-step agent workflows can also retain execution traces and tool-call records for investigation.

Could an AI agent execute operations on its own?

Within an approved scope, yes. Agent tools, permissions, and operating boundaries are specified in advance and checked at execution time. Routine tasks can be automated; high-risk or irreversible actions require human approval or other controls agreed during design.

What do you do to counter prompt injection?

We treat external content as untrusted, enforce instruction and tool boundaries, and apply authorization checks to tool operations. Higher-risk actions are subject to additional safeguards.

AI-specific test cases, including adversarial prompts, are included where relevant, and results can be provided as part of the agreed review materials.

Could employees use the AI to extract content from documents they are not authorized to view?

We design retrieval and tool access around each user’s permissions, with least-privilege authorization and tests for unintended disclosure. Where supported, authentication integrates with the customer’s existing identity system.

May we share your AI governance materials with our own customers?

Yes. You may share this public page with your customers. We can also support security questionnaires, technical briefings, and customer-specific governance discussions.

Governance Review

Discuss Your AI Governance Requirements.

Review your requirements for data use, AI autonomy, evaluation, oversight, and auditability with our technical team. We also support governance and security questionnaires during vendor assessments.

Discuss Governance Requirements