Skip to main content
project@netbasejsc.com
Mon–Sat: 9:00–18:15, Sun: closed
91 Nguyen Chi Thanh, Hanoi
Facebook X (Twitter) LinkedIn YouTube

What are you looking for?

Explore our services and discover how we can help you achieve your goals

Emerging technology adoption: decide before scaling

Adopt an emerging technology only after one named workflow, an accountable owner, a representative case set and a written stop rule exist. The first experiment should observe, classify, draft or recommend rather than act on its own. It earns a build when it beats the current process on cases the owner agreed before testing began.

Submit a project Assess a workflow first

Reviewed by Huy Nguyen (David), CEO · Updated 15 Oct 2026 · 11 min read

star

OutsourcingVN is operated by Netbase JSC, which sells the assessment and build work described here, so we have an interest in your decision. The method applies whoever you buy from. This guide is written for CTOs, operations leaders and risk owners weighing an AI agent, a retrieval assistant, a document model, an edge device, a speech interface or a robotics component.

What this guide covers

Which question is the technology supposed to answer?

Before choosing anything, write one sentence in this form: "In the [workflow] step, [owner] decides [what] using [inputs]; we want to know whether [technology] can [observe, classify, draft or recommend] well enough to change that decision."

Each technology raises its own question and has a focused guide:

For workflows where AI does one step of an ordinary business process, the AI workflow automation guide covers selection, testing and accountability in more depth.

Which route fits your situation?

Situation Sensible next move Evidence before commitment
A repetitive decision with past examples and one owner Run a bounded, recommendation-only experiment Baseline of today's handling, labelled cases, acceptance rule
The workflow needs several systems to change data Design the authority boundary before any model work Permission matrix, approval point, audit trail, rollback
Records are incomplete, scattered or of unclear ownership Fix data ownership and access first Named source owners, access rights, refresh process
The output drives a physical or safety-relevant action Commission qualified domain and safety review Hazard analysis, simulation scope, explicit exclusions
A conventional rule or integration already solves it Build the rule and skip the model A written comparison of both routes

An AI Workflow Blueprint is the assessment route when these questions are still open. Its useful output can be a narrower opportunity, a conventional solution or a recorded decision to stop.

How do you set the experiment boundary?

  1. Name one operational question

    State the workflow step, the current owner, the input types and the decision the experiment will inform.

  2. Choose representative cases

    Include normal, incomplete, ambiguous, adversarial and out-of-scope inputs. Record who supplied them, what may be retained and how correct handling will be judged.

  3. Limit authority

    The first version observes, classifies, drafts or recommends. Sending, purchasing, changing records or moving equipment waits for an explicit approval path.

  4. Write the stop rule

    Missing data rights, an error pattern the owner cannot accept, no improvement over the baseline, a review burden that erases the benefit, or a control that cannot be built each end the experiment.

  5. Decide with the owners in the room

    The workflow owner, technical owner and security or privacy owner each accept the next step or record why it stops.

Diagram of an experiment boundary pipeline: one question, representative cases, limited authority and a stop rule lead to an owners' decision, a recommendation-only step and the stop rule as the way back
Diagram of an experiment boundary pipeline

A worked example: support triage, recommendation only

A distribution company wants a model to route inbound support email. The support lead is the workflow owner; the IT manager owns the mailbox connector; the data protection lead owns retention.

The team pulls typical past emails, then adds awkward ones: a complaint written in two languages, a request with no order number, and an email that asks for a bank detail change. The acceptance rule is written first. An ordinary request gets a suggested queue and a one-line reason that cites the email text. An incomplete one gets a suggested clarifying question. The bank detail change is always marked "hold for staff" and never routed automatically.

During the test, the model can only write a suggestion into a side field; agents keep routing as before and mark whether it was right. At review, the support lead compares suggestions with agent decisions, the IT manager confirms the connector never had send or delete scope, and the data protection lead confirms test emails were purged on schedule. The outcome is one of three recorded decisions: extend to live suggestions, narrow to the queues where suggestions matched agents, or stop.

How should agents and tool access be controlled?

Agent and Model Context Protocol designs add a separate question: which tool may act, with whose authority, on which resource. The MCP authorization specification describes an OAuth-based flow for protected HTTP transports, with tokens bound to the intended resource and audience checks on the server.

Treat retrieved documents, webpages, uploaded files and tool responses as untrusted. OWASP describes direct and indirect prompt injection, including instructions hidden inside ordinary-looking content. In practice that means:

  • Keep credentials in the application. The model requests an action; deterministic code checks it against an allowlist and holds the token.
  • Validate structured output. Parse every tool call against a schema and reject anything outside it.
  • Require a person for privileged actions. Writes, payments, deletions and external messages wait for an approval step.
  • Test hostile cases on purpose. A document telling the model to ignore its instructions, a request that crosses a tenant boundary, and a fabricated tool result belong in the case set.

What has Netbase delivered with AI?

Netbase works with commercial and open-source AI models chosen per project. Netbase applies the ISO/IEC 42001 AI management system framework to its own AI delivery practice; that practice covers Netbase's own work and does not extend to a client's system.

  • In delivered work

    Product recommendations for 4over4

    For 4over4, Netbase built a recommendation engine that suggests products from browsing history and previous purchases. The same project's conversion of Illustrator files to SVG is file-format automation, not AI.

  • In delivered work

    WhatsApp chatbot with CRM sync

    Netbase built a WhatsApp Business AI chatbot with intent and conversation-flow handling, an LLM API (GPT-4 in the stack) and CRM synchronisation, delivered in milestones from design and prototype to knowledge transfer and 30 days of support over 4-8 weeks.

  • In delivered work

    AI flagging into human moderation

    A classifieds platform used AI-powered content filtering that detects and flags offensive content into an admin moderation dashboard, where a person decides.

  • In delivered work

    Retrieval assistants, document AI and MLOps pipelines

    Netbase has delivered anonymised client AI projects including retrieval-based knowledge assistants, document AI and MLOps pipelines.

  • Available capability

    Agents, edge, speech and robotics software

    Netbase takes these on through a scoped assessment that starts from your data, your devices and your named risk owner.

Which questions should you ask a supplier?

  • Which decision will this experiment change?

    One workflow step, one owner, and the decision named in a sentence

  • What cases will you test, and who picks them?

    Cases chosen with your team, including awkward and hostile inputs, before any build

  • What may the system do on its own?

    A short list of read or suggest actions; every write held for approval

  • Where do credentials live?

    In application code or a secret store, never in prompts or model context

  • How will we know it failed?

    Stop conditions written before testing, with the owner who calls them

  • What happens when the model or prompt changes?

    The case set is rerun and the result recorded before release

  • Who owns the system after handover?

    Named roles for operation, review and rollback, with documentation

  • What delivery record backs your proposal?

    Specific records, what each covered, and where the proposal goes beyond them

What failure modes should you watch for?

  • The demo used clean cases only

    Early signal
    Accuracy drops on the first real week of inputs
    Who acts
    Workflow owner reopens the case set

  • Scope creep from suggest to act

    Early signal
    A request to "just let it send" before review
    Who acts
    Security owner blocks until an approval path exists

  • Review burden erases the benefit

    Early signal
    Staff spend longer checking than doing
    Who acts
    Workflow owner narrows or stops

  • Silent model or prompt change

    Early signal
    Output format or tone shifts without a release note
    Who acts
    Technical owner rolls back and reruns cases

  • Injected instructions in content

    Early signal
    A tool call nobody requested appears in logs
    Who acts
    Security owner disables the tool and investigates

  • No owner after the pilot

    Early signal
    Nobody answers when the suggestion queue backs up
    Who acts
    Sponsor assigns an owner or retires the system

Plan the next step for your project

Submit a project Assess a workflow first

Common questions

No. Use the smallest representative set that can lawfully be reviewed, drawn with the data owner's approval. If the evidence needed cannot be accessed at all, record that limitation and decide whether the experiment can still answer its question.

Only for low-consequence, reversible actions, after the owner accepts a permission boundary, logging and a disable route. Early experiments should stay recommendation-only. Moving an action from suggested to automatic is a new decision with its own case set.

A prototype answers the question its cases and controls posed. Production also depends on integration, access control, monitoring, support ownership and inputs that drift over time, so it needs its own assessment before live traffic reaches it.

Long enough to see the normal mix of cases, including the rare ones the owner cares about, and short enough that the stop rule still means something. The case set, not the calendar, decides when the evidence is sufficient.

Start with the decision and the data boundary, then choose. Data residency, operating effort, skills and the need to switch later usually decide it. A design that keeps the model behind an interface lets you change the choice after the first evaluation.

How this guide is sourced

Statements about Netbase map to approved claims backed by attested company facts listed under Sources, published in their registered wording. External guidance comes from the MCP authorization specification, OWASP's prompt injection entry and NIST's generative AI profile, each dated below. The worked example is illustrative and describes no client. Agents with tool access, edge inference, speech interfaces and robotics software are offered through the scoped assessment described above. It does not replace your own legal, security or safety review. For how claims are reviewed site-wide, see the methodology.

Bring one workflow and its owner

The fastest useful first conversation starts with one workflow, the person who owns it and a handful of real cases, including the awkward ones. Submit a project with those three things, or browse the other guides first. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.

AI workflow blueprint: decide where automation belongs before you build AI workflow blueprint: decide where automation belongs before you build

A paid two-to-four-week project that ends in a scope you can approve, change or stop.

Learn More
line

Sources

91 Nguyen Chi Thanh, Hanoi

+84 937 869 689

Tell us what you want to build or automate.

Submit a project