Selecting and Orchestrating Domestic LLMs in Highly Regulated Enterprise Environments

1. The Model Selection Dilemma in Highly Regulated Environments

In government and state-owned enterprise IT projects, data security and compliance are the overriding priorities. Driven by comprehensive considerations of data sovereignty, sensitive information control, and supply chain security, these projects enforce strict technical red lines: the use of international LLMs and their associated agentic orchestration frameworks is prohibited. This means that even if certain globally leading models perform exceptionally well on general benchmarks, they cannot be included in the candidate list for such projects.

This constraint fundamentally alters the daily workflow of developers. Engineers accustomed to relying on a single model for everything must now confront a practical reality: Within the confines of domestic models and domestic toolchains, how can they find a solution that satisfies compliance requirements while efficiently executing complex business logic? The answer is not simply choosing the model with the highest benchmark score, but rather deeply understanding the capability layering of models and how they align with specific project requirements.

2. Model Capability Layering: Intent Understanding vs. Instruction Execution

To make the correct selection decision, it is first necessary to establish an evaluation framework for model capabilities. Based on engineering experience, the capability differences among LLMs primarily manifest in two dimensions:

Dimension 1: Precision in Instruction Following. This refers to the model’s ability to strictly execute tasks according to boundary conditions, contract definitions, and constraint rules provided by developers. For example, if a developer specifies in the prompt “only lock the primary key ID, do not lock the folder ID,” the model must accurately recognize and execute this constraint.

Dimension 2: Intent Understanding and Fuzzy Reasoning. This is the model’s ability to deduce the developer’s true design intent when instructions are ambiguous, context is incomplete, or multiple solutions exist. It requires the model to possess a composite literacy of common-sense reasoning, code semantic analysis, and business logic judgment.

Small-parameter models (such as lightweight code models offered by certain cloud vendors) typically perform well in the first dimension. Trained on massive datasets for code completion, unit test generation, and simple refactoring, they can quickly respond to instructions with clear boundaries, offering fast generation speeds and lower inference costs. However, their weakness lies exactly in the second dimension: when instructions are slightly ambiguous or require comprehensive judgment based on project context, they tend to provide solutions that “appear reasonable but actually deviate from the original design intent.”

3. Case Study: A Design Deviation in Locking Logic

Let’s examine the practical impact of this difference through a real project’s code logic design process.

An enterprise information system involves the associated management of data and archives. At the database level, a single data record may correspond to multiple archive files. To prevent data inconsistency during concurrent multi-user operations, a pessimistic locking (exclusive lock) mechanism is required. The developer’s design intent was to: directly lock the primary key ID of the data table. This way, when a user is operating on a data record and its associated archives, any modification or deletion operations by other users on that data would be blocked, thereby ensuring transaction safety and significantly simplifying subsequent cascade deletion and update logic.

To facilitate the LLM in generating this locking code, the developer provided a concise prompt: “When updating an archive, an exclusive lock needs to be added to prevent concurrency conflicts.”

Upon receiving this instruction, a small-parameter model typically responds by locating the operation logic of the archive table and then locking the archive folder ID. From the perspective of code compilation and unit testing, this logic is indeed effective—it does prevent concurrent modifications to the same archive folder. However, the problems are:

1. Logic Redundancy: Because the lock granularity is incorrect, developers must write additional nested synchronization layers to coordinate the relationship between “primary key data locking” and “archive operations.”
2. Potential Risks: Since the primary key ID of the data is not locked, while one user is editing an archive, another user can directly delete the entire master data record. This turns the archives into orphaned data, causing unexpected runtime exceptions.
3. Maintenance Burden: Engineers taking over the project later must spend extra effort understanding this “accidentally correct” locking logic, increasing the project’s implicit technical debt.

Conversely, when a large-parameter model (possessing stronger intent reasoning capabilities) receives the same instruction, it often contextualizes the “dependency between data and archives” and the “risk points of concurrent operations” to actively infer that “the locking object should be the data primary key ID”—an implicit and superior design solution.

This case clearly reveals the essence of the problem: Small-parameter models excel at “following the book,” while large-parameter models excel at “reading the room.” In complex enterprise systems, the latter capability often directly determines the architectural quality and operational stability of the system.

4. Wishful Programming vs. Engineering Constraints

The industry has popularized a development approach known as “wishful programming”—where developers simply describe “the effect they want,” and the LLM automatically generates the corresponding implementation logic. While effective for rapid prototyping, directly applying this to enterprise project delivery presents a clear cognitive trap.

The core of formal project delivery is the contract, not a “flash of inspiration” optimal solution. Project code must conform to team-agreed architectural standards, naming conventions, logging standards, and exception handling chains. It must prioritize readability and maintainability while meeting performance thresholds. Sometimes, an engineer might have a “simpler but less universal” algorithm in mind, but for the sake of team collaboration consistency, they will choose a longer but more straightforward implementation. In such cases, the LLM should not reinvent a solution, but rather provide assistance steadfastly within the design boundaries set by the developer.

This is exactly where the value of the second dimension of large-parameter models lies. They can understand that “although another solution exists, the developer has made a trade-off based on project considerations, and I should follow this direction.” Small-parameter models often lack this judgment of “contract spirit” and tend to improvise during code generation, introducing unexpected side effects.

5. Synergy Beyond Model Capabilities: A High-Baseline Orchestration Pattern

Based on the above analysis and practical experience within the confines of compliant domestic tech stacks, it is recommended to adopt a “Deep Understanding Model + Lightweight Execution Model” high-baseline orchestration pattern, rather than relying on a single model.

The basic division of labor for this pattern is as follows:

• Deep Understanding Model (Large Parameters): Responsible for global design reviews, complex business logic deduction, code architecture decoupling, and completing ambiguous requirements. When developers provide vague top-level instructions, it can infer the full picture of the “contract” based on context, helping to calibrate the design direction.
• Lightweight Execution Model (Small Parameters): Responsible for high-frequency, low-ambiguity code generation tasks, such as generating boilerplate code (getters/setters), writing unit tests for isolated functions, batch renaming variables, and formatting code styles. These tasks have clear boundaries and do not require heavy context reasoning. The lightweight model’s advantages in inference speed and concurrent processing can be fully utilized.

Through upfront intent parsing, a developer’s natural language requirements can first be handed to the deep understanding model for structured breakdown, generating clear task descriptions and constraints. The lightweight execution model then takes over for actual code generation. This cascading pattern ensures the effectiveness of complex tasks while controlling overall API call costs and latency.

6. Selection Recommendations: Building a New Dual-Model Workflow

For teams leading technical selection in highly regulated projects, the following practical recommendations are provided:

1. Establish a project-level model evaluation set instead of relying on general benchmarks. Select code commit records from the team’s last three complete iteration cycles, including bug fixes, refactoring, and new feature development. Use candidate models to generate results respectively, compare the differences against the finally merged code, and use the “final merge rate” as the core KPI.

2. Emphasize prompt contract design. Promote a “structured prompt template” within the project. The template should explicitly list three elements: “Target Object,” “Boundary Conditions,” and “Prohibited Actions.” This not only reduces the probability of model misunderstanding but also allows for quick problem source identification when model outputs are abnormal.

3. Build a dual-model switching mechanism. Integrate the deep understanding model as the default entry point in the development environment, while configuring the lightweight model for rapid processing of simple tasks. When the deep understanding model times out or budget constraints apply, it can temporarily downgrade to the lightweight model, paired with more refined prompts, ensuring core development workflows remain uninterrupted.

4. Foster a culture of human review. No matter how powerful the model, the ultimate responsibility for code review in enterprise projects still rests with senior engineers. Model-generated code must go through a standard Code Review process. Particularly for critical security logic involving database locks, transaction boundaries, and permission checks, line-by-line confirmation is mandatory.

7. Conclusion

The value of compliant models in highly regulated projects is no longer limited to the substitution level of “can it be used,” but is entering the selection and orchestration level of “how to use it well.” Small-parameter and large-parameter models each have their strengths. True engineering wisdom lies in dynamically orchestrating model roles based on task nature, building an intelligent development baseline with understanding capability as the core and execution capability as the periphery. Only in this way can delivery efficiency be ensured while maintaining the baseline of system quality within the high walls of compliance.