Every AI project in Iran meets three knots before the conversation reaches architecture or model choice: limited access to global services, unstructured data, and specialist talent that is hard to find and harder to keep. Projects fail on these far more often than on the choice of algorithm.

Yet the same context also produces openings that would be meaningless in a saturated global market. Reading both sides of that equation is the difference between realistic planning and fruitless waiting.

The three knots every project reaches

• Access: resting an architecture on a service that may be gone tomorrow is an operational risk, not an inconvenience.
• Data: it exists in most companies, but in scattered files, handwritten logs and free-text fields; between holding it and using it lies a gap that must be paid for.
• Talent: the market for experienced engineers is competitive and the incentive to emigrate real; all knowledge in one person is stockpiled risk.

The access knot: from working around to replacing

The durable answer is not a temporary route to a blocked service; it is an architecture that gathers the dependency into one replaceable layer. If all model traffic passes through a single point, substituting an open-weight model on internal servers is a contained change, not a rewrite. Open models now cover most enterprise use cases.

The data knot: harder, and therefore more valuable

Persian text has its own problems: right-to-left script, similar characters across two keyboard layouts, the zero-width joiner and several written forms of one word. These raise the cost of entry, and for that reason whoever solves them builds an asset foreign vendors have little reason to build. Data normalization affects quality more than model choice.

The talent knot: retention matters more than hiring

An organization that leaves project knowledge undocumented pays for every departure by starting over. Three measures reduce the risk: documenting architectural decisions, involving internal staff in contracted work, and training business experts to use the tools.

Openings that only make sense in this context

• A domestic market with little competition: many processes here still have no intelligent solution; the contest is about arriving, not differentiating.
• Localization as a requirement: access limits create durable demand that a global price cut does not erase.
• Knowledge close to the field: local regulation, purchasing habits and customer language are the layer a generic product lacks.

A practical example

Consider a company holding years of inspection reports as free Persian text, an archive treated until then as storage overhead. By tidying those texts and building a semantic search over them, engineers could retrieve comparable failures in seconds. The investment went into cleaning data that already existed, not into a model.

A 90-day starting path

• First month: inventory the data you hold and choose the process whose data is most complete.
• Second month: build the pilot on a replaceable architecture and weigh the on-premise option early.
• Third month: measure against one business metric, document the decisions, and widen the scope only if it improved.

Common mistakes

• Binding the architecture to one external service with no substitution path.
• Starting before answering where the required data sits and in what state.
• Handing the whole project to a contractor with no knowledge transfer inside.
• Expecting results from a demo never connected to a real process.

Frequently asked questions

• Do domestic open models match global services?
  For most enterprise use cases, yes; the remaining gap is smaller than the one data quality creates.
• If our data is untidy, how far behind are we?
  You are at step one, not behind; tidying the data of one process takes weeks, not years.
• Can we begin without a machine learning specialist?
  For ready-model use cases, a software engineer who knows the domain is usually enough.

Takeaway

The constraints of this market are real, and denying them helps no project; but all three knots have known answers. Treated as design requirements rather than obstacles, they yield a solution that is more independent and closer to its market.

Glossary

• Open-weight model: a model whose weights are available, runnable on your own servers.
• On-premise: running software and models on the organization's own servers.
• Structured data: data stored in a defined, machine-processable form.
• Semantic search: retrieval based on meaning rather than word matching.
• Replaceable layer: the part you can change while the rest stays intact.