Asset records get created when inserting CMDB CIs, when the CI's Model is set as Asset tracking strategy=Don't create Assets.
This could happen when a Model Category is set up to synchronize CIs and Assets by default, but specific Hardware Models are set not to. It is due to the initial insert not having the final Model value set yet, in which case it is empty or uses the "Unknown" model, and that does allow Asset creation. A subsequent update then sets the Model, perhaps in the same transaction, but by then it is too late.
By checking the audit history of the CI from History - List you can confirm from the Update Numbers. Update number 0 is the initial insert, and if Model ID is set as Unknown or empty then you may have this problem. You will see the subsequent update of that from Unknown to the proper value in Update Number 1 or higher.
In this situation, the Asset Management CI-Asset synchronization is working as designed.
Features that populate the CMDB should insert the CI in one go, or at least make sure the initial insert includes the correct/final Model value. If an out-of-box feature isn't doing this then please report the issue to Customer Support.
Find the 'Unknown' Model(s) that includes the Model Category for the Class of the CI that is being inserted, and set it as Asset tracking strategy=Don't create Assets as well.
Inserts using that "Unknown" Model will now not cause an Asset to be created. Subsequent updates to the Model of the CI will either create an asset or not, depending on the asset tracking strategy of the model you change it to.
Since Berlin/Calgary, the "Don't create Assets" setting on the Model is used. Since then all inserts like this should work in general. (PRB577712)
The Discovery feature used to have a problem with this until the Dublin release (PRB585012). It would insert the CI then update the model later, causing this issue. However that predates the Identification and Reconciliation API, and Patterns, and so may still theoretically apply to Discovery.
The Kingston release improved this by using the "Unknown" Model record for the Model Category if the CI was inserted with a blank Model reference (PRB678850). That helps with the workaround.
The Microsoft SCCM Integrations may still have this issue. Other sources of CI data may also have this issue depending on exactly how the CIs are inserted.