The model is the last decision, not the first

OutsourcingVN is operated by Netbase JSC, which builds and runs these workflows, so we have a commercial interest in your decision. Netbase works with commercial and open-source AI models chosen per project, and no vendor partnership is implied by any technology choice here. This page is a spoke of the AI workflow automation guide.

Why the model is the last decision

Buyers arrive with a model in mind because models are what the market talks about. The model is the part of the system that changes fastest, is easiest to replace, and contributes least to whether the workflow works.

What actually decides the outcome is upstream of it: whether the task is well defined, whether the inputs are clean and available, whether you have the right to use the data for this purpose, whether anyone can say what a correct result looks like, and where a person stays in control. Those questions are answered by the workflow design, not by a model card. A well-designed workflow with a mediocre model beats a badly scoped one with the strongest model available, and it keeps beating it after the next release.

There is a practical reason to hold the decision late. Whatever you choose today will not lead in a year, and if the choice is embedded in your architecture you pay twice: once when the model is retired, once when you find you cannot test the replacement. Deciding late and reversibly is the discipline.

Match the model class to the task class

Most business workflows decompose into a few task classes. Each has a model class that suits it, and the mismatch — a large general model where a small specific one belongs — is where projects waste effort.

Netbase has delivered anonymised client AI projects including retrieval-based knowledge assistants, document AI and MLOps pipelines, which is the experience behind the rows above. The table is engineering judgement about task fit, not a ranking of products.

The selection criteria you actually control

Leaderboard positions move every few weeks and are measured on tasks that are not yours. The criteria below are stable and yours to set.

Where the data may be processed and stored. This is usually the deciding constraint and it should be settled first, because it eliminates options before any of them are tested. Write down which data classes the workflow touches, which of them may leave your infrastructure, which jurisdictions are acceptable, what retention you will accept, and whether your inputs may be used to improve someone else's model. Netbase security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request; data security and compliance in outsourcing sets out what to ask for and what we do not claim.

Latency and throughput the workflow needs. Not the fastest available: the fastest the workflow requires. A conversational workflow needs a first response in the time a person will wait. A nightly batch does not care. A webhook-triggered workflow cares about the timeout of whatever called it. Write the number down first, because latency is the criterion most often quietly traded away.

How a change of model is tested. You need an evaluation set before you need a model. It is the only instrument that answers "is the new one better for us", and without it a swap is a guess dressed as an upgrade. Building that set is the subject of AI workflow evaluation and testing, and it is the artefact that most determines whether you stay free to change.

What happens when a provider retires or changes a version. Assume it will happen inside the life of your workflow. Pin the version explicitly rather than tracking a floating alias, subscribe to the deprecation notices, keep a second candidate that has been through your evaluation set, and know how long you would need to switch. A workflow that cannot survive a deprecation notice is not a system, it is a dependency.

Commercial terms belong in the same conversation but not on this page: they move too fast to publish and they are agreed per project.

Self-hosted open-weight versus hosted commercial

Netbase works with commercial and open-source AI models chosen per project. Neither is the default answer, and the honest comparison is narrower than the argument usually gets.

Self-hosted open-weight models are right when data may not leave your infrastructure, when you need a version nobody can retire from under you, when the workload is steady enough to justify running it yourself, or when a smaller specialised model does the task. What you take on is real: capacity, updates, monitoring and the engineering to keep it healthy. That work does not disappear because the weights are free.

Hosted commercial models are right when capability matters more than control, when demand is spiky, when the team is small, or when you want the strongest option for a hard task without an infrastructure project attached. What you take on is a dependency you do not govern: versions change, terms change, availability is somebody else's decision.

Many workflows end up mixed, and that is a legitimate design rather than a failure to choose: a small self-hosted model for high-volume classification, a hosted model for the low-volume hard cases, with the routing between them an explicit part of the workflow. If you have not yet decided which part of the work should be automated at all, a short paid AI workflow blueprint settles that before the model question is worth asking.

Designing for replaceability

The architectural rule is simple to state and easy to violate: the model is a component behind an interface, not the shape of your system.

In practice that means the workflow calls your own interface rather than a provider SDK spread through the codebase; prompts, schemas and thresholds live in configuration you can version, not inline in application code; provider-specific features are isolated behind that interface so their absence elsewhere is a known gap, not a surprise; outputs are validated against a schema your system owns; and the evaluation harness can point at any candidate without changes to the workflow. Add a fallback path so an outage degrades the workflow instead of stopping it, and log which model and version produced every result, because you cannot investigate a regression you cannot attribute.

None of this is exotic. It is the separation you would apply to a payment provider or a mail service, and the reason to insist on it here is that this dependency changes faster than either. It also keeps the interesting decisions where they belong: the review design in human-in-the-loop AI workflows, and the workflow-versus-agent choice in AI agents versus workflow automation.

Keep the model replaceable from day one

Netbase delivers remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. One delivered record on this site names models as part of a stack: an anonymised WhatsApp Business AI chatbot with CRM integration built with intent and conversation-flow handling, an LLM API with GPT-4 in the stack, and CRM synchronisation. That is a record of what was built, not a recommendation, and our evidence rules are on the methodology page. When you are ready, submit a project with your data constraints and latency requirement, and we will scope the selection as part of the build under AI workflow automation. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.

Related services and solutions