Identify the layer that is actually blocking the work
An AI project can stall because the team lacks compute, cannot transfer a dataset, has no suitable model or cannot safely connect to its records. Buying more hardware will not resolve every one of those problems. Kooya recommends naming the constraint before choosing an infrastructure program.
This article separates the documented services from our recommendations for using them. It does not report an authenticated test of their capacity, uptime or model performance. The practical objective is to help a research team prepare a precise inquiry rather than assume a national platform automatically fits its workload.
COARE provides a research computing foundation
ASTI’s COARE project page describes a facility established in 2014 that provides high-performance computing and cloud access to students, researchers and data analysts. Its purposes include computationally intensive analysis and the storage and sharing of research data.[2]
Kooya’s reading is that a university group or agency research team should begin with a workload description. Record the size and format of the dataset, the software needed, the expected runtime and whether the work needs accelerated computing. Distinguish a one-time experiment from a continuously running service.
Those details help the service team assess fit. They also prevent a misleading comparison between shared research capacity and a commercial deployment with a different availability requirement. Free access in a project description should not be read as unlimited resources for every proposed use.
Use the current policy to establish the boundaries
COARE’s Acceptable Use Policy version 10.1, dated 28 April 2026, limits use to R&D and scientific studies. Accounts and increased allocations require the team’s approval. Users must maintain their own data copies and should not treat COARE as their sole repository.[1]
Kooya recommends asking for written confirmation of the proposed use, resource allocation and support arrangement before making an external delivery commitment. An experiment serving researchers and a customer-facing business workflow can have very different requirements; eligibility should be established for the actual activity.
Prepare an exit plan alongside the application. Know how to retrieve datasets, code, evaluation results and configuration when the research finishes. Keeping the experiment reproducible makes it easier to continue on another environment if project scope or access changes.
PREGINET addresses institutional connectivity
PREGINET interconnects academic, government and research institutions. ASTI’s published joining process includes a letter of intent, a requirements discussion, a proposal with costs, last-mile arrangements and a memorandum of agreement. It is a research network, rather than an AI model catalogue.[3]
For a distributed project, Kooya recommends drawing the data journey: where records originate, which institution processes them and who needs the outputs. Estimate transfers and identify the organization responsible for each connection. Connectivity decisions become clearer when tied to a real workflow.
The underlying project page carries older technical figures, so this article does not repeat them as current bandwidth promises. A prospective partner should obtain a current design and costing for its location. Access to a network also does not confer permission to use another institution’s data.
DIMER provides a route to model reuse
ASTI’s June 2025 DIMER report describes model sharing and an inference interface that can run models without requiring users to download and reconfigure them. It traces the technology to ASTI-ALaM and describes its integration into the DOST-NAIRA project.[4]
A reusable model can shorten the path to an experiment, but Kooya recommends treating its published purpose as the starting point for evaluation. Check whether its inputs resemble the proposed dataset, whether its outputs answer the operational question and whether the relevant terms permit the intended use.
A model that recognizes features in one collection of imagery may require additional validation on another. Keep a local set of representative examples and record the cases that fail. Model reuse should reduce duplicated development without removing the receiving team’s responsibility to assess fitness.
Keep platform maturity visible in the plan
ASTI’s 6 April 2026 program review calls DIMER a public beta. It describes development toward no-code and low-code AI-as-a-Service, with an expanded workbench planned for Year 3. That is more qualified than a claim that every planned production capability is already available.[5]
Kooya recommends separating a successful exploration from a dependency that a live operation cannot afford to lose. For a beta platform, confirm the support channel, change notices, export options and what happens when an interface changes. Limit an initial trial to work that can be checked and recovered.
The responsible conclusion is specific: an existing platform can be useful while still evolving. Its availability does not remove the need to verify current features, access conditions or suitability for a particular service.
The NAICRI brief places these evolving research services in the wider effort to sustain AI capability beyond individual projects.
A language interface does not settle the data question
The same April review describes iTANONG as a database interface supporting English, Filipino and Taglish, designed for secure on-premises deployment. ASTI’s technology-transfer page still lists iTanong as coming soon. These sources do not establish a universal commercial rollout.[5][6]
Kooya’s recommendation is to evaluate a database assistant around the exact records and permissions it will encounter. A natural-language question should not make restricted rows visible or turn an ambiguous request into a confident answer. Agree on the authorized users and the questions the system is allowed to answer.
For a first trial, use controlled records and compare the result with a known query or a qualified reviewer’s answer. Include unclear dates, missing fields and mixed-language phrasing. Judge correctness and access behavior independently from how natural the response sounds.
DICT’s public-service approach is a separate deployment track
Google Cloud’s June 2026 joint-collaboration announcement describes DICT’s plans to integrate AI agents into e-government services and expand access to enterprise AI tools. It also reports an AI-supported cyber-defense deployment at the National Security Operations Center. These are the participating vendor’s published statements; the planned civil-service rollout should not be read as a completed adoption count.[7]
The distinction from ASTI’s research services is operational. A government office buying or integrating an enterprise service needs its own procurement, permissions, support and evaluation arrangements. Kooya’s recommendation is to ask which service can support the actual workload today, rather than treating a research allocation, a beta platform and a commercial public-service initiative as equivalent sources of capacity.
Prepare an infrastructure request that can be answered
Kooya recommends a compact request containing the research objective, accountable institution, dataset description, authorization, software dependencies, resource estimate and intended duration. Add the evaluation method and the person responsible for incident handling. That gives the receiving team information it can act on.
For example, a fictional university team testing a classifier could request capacity for a fixed dataset and a bounded series of experiments. Its brief would specify permitted data, expected outputs and how the results will be preserved. A later operational deployment would need its own confirmed arrangement.
This approach makes shared infrastructure part of an implementation plan rather than a promise of effortless adoption. The important decision is whether the available layer, its rules and its maturity match the work the team is actually ready to perform.