Robo Claw's Pilot, PoC and Validation Method for NGOs
Based on the requirements defined in the Refine STEP, this builds Agents, Skills and Tool Policies within a limited scope of 1 business, 1 region, 1 language, 1 channel, 1 data category and 1 system connection, and validates misclassification, misrepresentation in summaries, mistranslation, misrecognition of supporter/donor information, contamination with beneficiary information, contamination with personal/sensitive information, misrecognition of grant/donation conditions, misrecognition of activity report/KPI information, misdirected sends, misdirected publication, incorrect updates, duplicate execution, duplicate sends, Prompt Injection, SaaS/API outages, API specification changes, human approval, stopping/rollback and switching to manual operation before deciding whether to move to production.
Who This Is For
Who This Is For
Intended for business owners, staff concurrently responsible for information systems, personal data protection officers, and local managers who defined requirements in the Refine STEP.
What You'll Decide
What You'll Decide in This Step
In the Build & Validate STEP, you build a Pilot within a limited scope, run normal-case and abnormal-case tests, and then decide whether to move to production.
Pilot Scope
Pilot Scope
Validating multiple businesses or multiple regions at the same time makes permission design and result evaluation more complex. We recommend limiting the first Pilot to the following scope.
1 Business
Even if you run multiple businesses, limit the first Pilot to 1 business.
1 Region, 1 Language
Narrow the target region and supported language down to one, making risk easier to assess.
1 Channel
Limit the digital channel used, such as email or social media, to one.
1 Data Category, 1 System Connection
Limit the data category handled and the system connected to, one each.
Industry Challenges
Common Challenges in a Pilot
Test perspectives are not covered comprehensively
Teams tend to check only normal cases, leaving abnormal-case tests such as misrecognition and misdirected sends insufficient.
Criteria for moving to production are not decided in advance
Projects sometimes proceed with what must be satisfied to move to production after the Pilot ends left ambiguous.
There is no procedure for switching back to manual operation
When a problem occurs during the Pilot, a procedure for switching to manual operation is sometimes not prepared.
The personal data protection officer is involved too late
Without involving the personal data protection officer from the test design stage, rework sometimes occurs later.
Method
Implementation Steps
1. Finalize the Pilot scope
Finalize the scope of 1 business, 1 region, 1 language and 1 channel.
2. Build the Agent, Skill and Tool Policy
Based on the design defined in the Refine STEP, actually build the Agent, Skill and Tool Policy.
3. Prepare test data
Prepare test inquiry and activity report data that does not include production personal information or sensitive information.
4. Run normal-case tests
Confirm whether initial classification of inquiries, drafting of replies, and report summarization are performed correctly.
5. Run abnormal-case tests
Based on the abnormal-case test items below, confirm behavior for misrecognition, misdirected sends, information contamination and outages.
6. Validate human approval, stopping and rollback
Confirm whether human approval functions correctly and whether the system can be stopped and rolled back when a problem occurs.
7. Validate switching to manual operation
Confirm whether the procedure for switching to manual operation functions when the Agent is stopped.
8. Decide whether to move to production
The business owner and personal data protection officer compare the test results against the Go/No-Go criteria and decide whether to move to production.
Test Scenarios
Abnormal-Case Test Items
Below are example abnormal-case test items to validate in a Pilot for NGO/NPO digital operations. Add and adjust these to fit your organization's operations and systems.
| Test Item | Assumed Scenario | What to Check |
|---|---|---|
| Misclassification | The type or priority of an inquiry is classified incorrectly | Whether misclassification is detected and corrected by a human |
| Misrepresentation in summaries | An error occurs in the summary content of an activity report or meeting record | Whether a human can check the difference between the content before and after summarization |
| Mistranslation | An error occurs in the translated content of a multilingual communication | Whether a human or multilingual staff member can check it before distribution |
| Misrecognition of supporter/donor information | A supporter's or donor's name or history is read incorrectly | Whether misrecognition is detected and corrected by a human before sending |
| Contamination with beneficiary information | Beneficiary information is unintentionally included in output | Whether it can be removed through pre-output filtering and human review |
| Contamination with personal/sensitive information | Unnecessary personal information or sensitive information is mixed into output | Whether it can be removed through pre-output filtering and human review |
| Misrecognition of grant/donation conditions | Grant conditions or the stated use of donations is interpreted incorrectly | Whether the responsible person can check the content when drafting a report |
| Misrecognition of activity report/KPI information | Local reports or KPI data are aggregated incorrectly | Whether the aggregated results are presented in a form a human can check |
| Misdirected sends | Content is sent externally to the wrong recipient or with the wrong content | Whether pre-send approval, send logs and a cancellation procedure for misdirected sends function |
| Misdirected publication | Unapproved content is published to a website or social media | Whether the design prevents publication without going through a pre-publication approval flow |
| Incorrect updates | Content in a knowledge base or CMS is updated incorrectly | Whether pre-update review and preservation of change history function |
| Duplicate execution | The same process is executed multiple times | Whether an idempotency check prevents duplication |
| Duplicate sends | The same communication or notification is sent more than once | Whether duplication is detected by checking send history |
| Prompt Injection | An instruction hidden in input data causes the Agent to behave unintentionally | Whether the design ignores suspicious instructions and does not proceed to finalized processing |
| SaaS/API outages | A connected SaaS or API does not respond | Whether the system fails safe on error and notifies the responsible staff member |
| API specification changes | The specification of a connected SaaS is changed | Whether anomalies are detected and automatic execution is halted until revalidated |
| Human approval | Finalized processing is about to execute before approval | Whether the design prevents sending or publication from being finalized without approval |
| Escalation | Output occurs that is suspected of affecting beneficiaries | Whether it is reliably escalated to the business, safety and personal data officers |
| Stopping/rollback | Response after incorrect output or processing occurs | Whether stopping execution and the procedure for restoring the prior state function |
| Switching to manual operation | A situation where the Agent is temporarily unavailable | Whether a procedure for switching to manual operation is in place and operations can continue |
| Production migration criteria | The migration decision at the end of the Pilot | Whether the responsible person can decide in line with the Go/No-Go criteria |
Data & Systems
Data and Systems Used
Human-in-the-loop
Where Human Approval Is Required
- Content review and approval of draft replies and draft reports
- Review by the responsible person of candidates relating to beneficiaries or personal information
- Content review before external sending or external publication
- The decision to stop and roll back when an anomaly is detected
Measurement
KPI
Abnormal-case test pass rate
Share of the defined abnormal-case test items that met the pass criteria
Human review rate
Share of output for which human review was carried out
Number of misdirected sends/publications
Number of misdirected sends and misdirected publications that occurred during the Pilot period
Pitfalls
Common Pitfalls
Skipping abnormal-case tests
Moving to production after checking only normal cases risks starting operation without noticing contamination with personal information or misdirected publication.
Testing with production data
Using production data containing beneficiaries' personal information or sensitive information as-is in testing creates unnecessary risk of information leakage.
Deciding Go/No-Go criteria after the fact
Without defining the criteria in advance, the decision to move to production becomes ad hoc.
Go / No-Go Criteria
Criteria for Moving to Production
- All defined abnormal-case test items have been confirmed to behave safely as expected
- The human approval and escalation paths have been confirmed to actually function
- The stopping/rollback procedure and the procedure for switching to manual operation have been tried and confirmed to function
- The business owner and personal data protection officer have reviewed the results and agreed to move to production
- There is a reasonable prospect that the production monitoring and logging setup will meet the requirements of Deploy & Operate
FAQ
Frequently Asked Questions
How long should a Pilot run for?
It depends on the volume of work and the number of test items, but a guideline is often several weeks to about one to two months. We recommend prioritizing coverage of abnormal-case tests rather than proceeding on a fixed timeline.
Is it OK to use production supporter data for testing?
We do not recommend it. Prepare anonymized/pseudonymized test data, and avoid testing with data that contains production personal information or sensitive information.
What is Prompt Injection?
It is the risk that an instruction hidden in an inquiry or external data causes the Agent to behave unintentionally. In the Pilot, you confirm that even suspicious instructions do not lead to finalized processing.
Who decides whether to move to production?
We recommend that the business owner and personal data protection officer decide by comparing the test results against the Go/No-Go criteria. Where safety or legal issues are involved, the relevant responsible person also joins the decision.
Let's work through your Pilot design and validation together.
You can review the scope, test items and Go/No-Go criteria, and discuss the Pilot structure on our official LP.